标签云

微信群

扫码加入我们

WeChat QR Code

I need multiple cases in switch statement in JavaScript, Something like:switch (varName){ case "afshin", "saeed", "larry":alert('Hey'); break; default:alert('Default case'); break;}How can I do that? If there's no way to do something like that in JavaScript, I want to know an alternative solution that also follows DRY concept.


To the one who voted to close this question. It is more than 5 years old and has an accpeted answer - why the close vote?

2019年10月21日10分50秒

surfmuggle because it's not necessary to add more answers.

2019年10月20日10分50秒

AfshinMehrabani maybe it can be protected, not closed?

2019年10月20日10分50秒

See:developer.mozilla.org/en-US/docs/JavaScript/Reference/…

2019年10月20日10分50秒

Somehow it works for me in Chrome, in the javascript console: switch('10') { case 1, '10': console.log('ok') } prints ok

2019年10月20日10分50秒

nafg: Try switch(1). The label here is just a comma expression.

2019年10月20日10分50秒

Barney No, without the break you can fall through to the next case.

2019年10月20日10分50秒

Seiyira by definition, there is no next case after the last. Besides, it's a default.

2019年10月21日10分50秒

believesInSanta it's literally just normal case fallthrough with weird formatting (spaces instead of newlines)

2019年10月20日10分50秒

I definitely prefer this version. Fall through is a bug-prone feature of switch ... case. It's too easy to forget a break statement, and if you use fall through intentionally, those forgotten break statements can be very hard to spot.This method lookup version also has lots of great features that switch ... case lacks, such as dynamic extensibility, or the ability to completely replace the object to accomplish mode switching. It's also easier to keep cleanly organized, and can lead to more maintainable code. See ericleads.com/2012/12/switch-case-considered-harmful

2019年10月20日10分50秒

I always add a comment //fallthrough in place of break whenever I intentionally omit the break. That helps to identify when it's a mistake and when it's intentional.

2019年10月20日10分50秒

Intuitive approach. However, for readability, I'd recommend to use the native switch statement.

2019年10月21日10分50秒

One can always scratch the left ear passing its right hand through the back of the neck... (sorry for my english, I mean: "one can always complicate things as much as possible...in this case, avoiding the switch statement in favor of this complicated solution doesn't seem to be the right thing to do...)

2019年10月20日10分50秒

I'm truly amazed how this has gotten 34 up votes. In terms of readability and maintainability, this is absolutely horrific. If I want to see what conditions will trigger something, a case statement is incredibly simple and easy to see by looking at the labels.On the other hand, your version would require someone read pretty much every single line and see what you assigned where.This also gets even worse the more cases you want to match.

1970年01月01日00分03秒

It's a common technique in a pletora of languages, not bound to JS

2019年10月20日10分50秒

What is the benefit of this over a switch?

2019年10月21日10分50秒

BryceSnyder the difference between an expression and a statement? Less typing? Fewer vertical lines consumed? Greater expressive power through succinctness and density of representation? Better semantics through the includes word? Take your pick.

2019年10月20日10分50秒

not yet tested but it would be interesting to modify varName inside the case expression, expect that varName is cached thou.

2019年10月20日10分50秒

alright for value varName is cached

2019年10月20日10分50秒

how does this relate to switch? can you clarify it?

2019年10月20日10分50秒

why would you want to make your code "hard to read".The first thing I was told as a programmer was to write code with the mindset that the next person reading your code is an axe wielding serial killer and he hates not being able to understand code.

2019年10月20日10分50秒

Hi Matt... I'm presenting it here as a proof of concept... anyway this form provides you more funcionality and flexibility... and you only use it if you want... or if you find a constrain in your usual form of doing things... consider ir as one more tool in your programmer toolbox...

2019年10月20日10分50秒

I think the syntax is the same as other JS environments.

2019年10月20日10分50秒

AfshinMehrabani It might be, I have only tested it in nodejs context.

2019年10月20日10分50秒

You don't need to use the g flag, since you're only using the regexes once and throwing them away. In fact, if you were keeping them outside the function, the g flag would harm you by trying to match from a non-0 index on subsequent .test(s. I also fixed a typo where the switch case was on sensor variable and not true constant for matching boolean expressions. See the edit.

2019年10月20日10分50秒

This is abuse of the switch statement. Just if (accessDenied.includes(varName)) return 'Access Denied!'; return 'Access Allowed.' is more than enough.

2019年10月20日10分50秒

Q pls which #ecma is this?

2019年10月20日10分50秒

Hi there. This is ES6

2019年10月21日10分50秒

This is the same answer as everyone else, i will fix the " that you forgot, but think about deleting this.

2019年10月20日10分50秒

classic jquery inclusion :)

2019年10月20日10分50秒

This is not how the switch statement is supposed to work. It’s just case "1":, not case (num = "1"):.

2019年10月20日10分50秒

Why not put day value inside case and document.getElementById("result").innerHTML = ....outside the switch and add the day value result at the end?

2019年10月20日10分50秒

Xufox I love how he literally overwrites num but it still works because the switch has already been evaluated and the assignment yields the value. This is programming by mutation/machine learning at its finest.

2019年10月20日10分50秒

If you put true as the switch expression, in the "case" statement(s) you can evaluate whatever you want provided you return a boolean

2019年10月21日10分50秒

I think what he meant is that you can put an expression inside the function, who will evaluate and return a dynamic value for the case, thus allowing all sorts of complex conditions

2019年10月20日10分50秒

For this StefanoFavero note you dont actually need a function, just (expression) in parenthesis, and the return value must be the input. See my answer

2019年10月20日10分50秒

why you minused it?? I advocate this solution because it provides a flexibility for complex conditions. Even if you dont like funcs as conditions, you may replace them with you multiple conditions such as switch(true) {case (var1 === 0 && var2 === true): {}}

2019年10月20日10分50秒