Don't see why not. It can make some convoluted blocks of ifs easier to read if you ask me. Nothing odd going on - switch just compares the value of one expression with the values of the expressions listed as the cases. We can match any expressions that are true.
It's probably not considered 'best' practice as it doesn't adhere to the irrational dogma of the high priests of 'clean' code
Frontend developer by day, iOS developer by night. Currently working on learning iOS development and my own blog, Mike Decodes, where I'm decoding the tech industry. Come hang out with me on Twitter!
There's literally no need for the last sentence of your comment.
As to why it's considered not a best practice: while you could definitely use a screwdriver as a hammer, that's not the intended use. It's an incredibly smart way of using the switch statement but it's not the way it's intended to be used and as such is harder for people to understand.
If we continually write code catering to the lowest common denominator of understanding, developers will never learn all about how the languages really work - denying them the chance to improve their knowledge.
I'm a firm believer in increasing real understanding of languages. We should never tell developers they 'must' do this, that, or the other - rather, we should let them learn real understanding of how stuff works... and then - armed with that knowledge they can decide how best they can utilise the language.
Showing them something that challenges their understanding of a language feature can only benefit them, by gaining a fuller understanding
Frontend developer by day, iOS developer by night. Currently working on learning iOS development and my own blog, Mike Decodes, where I'm decoding the tech industry. Come hang out with me on Twitter!
This isn't about catering to the lowest common denominator, though. This is about writing clever code that has no reason being clever. It doesn't add to a person's understanding of how the language works because, like I said, it's telling someone to use a screwdriver as a hammer. The entire premise of the switch statement is to compare the expression to the cases.
Your code works, I'm not arguing that, just like you could easily hammer away at a nail using a screw driver but at what cost?
The entire premise of the switch statement is to compare the expression to the cases.
Which is precisely what my example is doing. Yes, it looks different to most examples of switch statements, but it's really no different - just comparing expression with expression
(I hope you don't find the self-promoted library distasteful - I link to others at the bottom of this very short article, and of course reference the TC39 spec for pattern-matching.)
By the way, I've found that even though switch (true) { ... } not so common, the reaction I usually see from those learning it for the first time is "Oh wow, you can do that?". There's just not a lot of friction to understanding it.
The entire premise of the switch statement is to compare the expression to the cases.
Which is precisely what my example is doing.
... for certain interpretations of 'precisely': switch(true) { case f(x): ...} is effectively, undeniably comparing true to a number of predicates.
It is effectively, undeniably not comparing a value unknown at design time to one of several, distinct, possibilities, all known at design time.
Proper understanding of the language would lead to the realization that this is the opposite of what switch is intended for.
When any developer, whatever their programming language, sees a switch, they will rightfully expect an enumeration of non-overlapping cases. This assumption allows them to effectively communicate intent.
Their surprise will lead to misunderstandings, lost time, bugs, everything the one paying for the code does not want.
We should distinguish 'understanding of languages' and 'understanding what the runtime makes of it'. If we mix these up, the latter interpretation would give us carte blanche to use whatever makes the program work and blame our colleagues for not 'understanding the inner workings'. I happily refer to Duff's device and isqrt for some examples of where this leads to; justified in some cases, but to be shunned in general.
switch(true) does not belong in production code. I will refuse to merge a pull request containing it.
Of course, every language needs poetry. So allow me to step out of my dogmatic production-code mindset, and appreciate the reversal of the intended use as an form of art.
When any developer, whatever their programming language, sees a switch, they will rightfully expect an enumeration of non-overlapping cases. This assumption allows them to effectively communicate intent.
I'm not convinced that intent is so clearly carried by syntax and convention alone. Surrounding context counts for a lot, and can make or break the understanding of any chunk of isolated code. I think it's perfectly reasonable to permit out-of-usual syntax so long as you can see what's going on when zooming out a bit.
I'm also not too sure that the two C/C++ examples you gave are germane. JS doesn't have proper pointers, let alone the ability to abuse them for type-casting. It can't have interleaved syntax either. switch (true), fall-throughs, and omitting default: are all naturally permitted by the spec.
If you don't like them, drop an eslint rule and they won't even make it into a PR. Incidentally, I wonder if a marvel like InvSqrt would even exist if we had linters back then? 🤔
Totally agree: syntax alone won't convey all your intent. Like a calligrapher can still write absolute nonsense. The point was that switch(true)... actively hides the intent.
Now that, I can appreciate: the great artist-inventor's role is to experiment with the know rules (hey someone has to do it!) and build interesting and beautiful devices, some adopted right away, others understood only after 400 years :).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Don't see why not. It can make some convoluted blocks of
ifs easier to read if you ask me. Nothing odd going on -switchjust compares the value of one expression with the values of the expressions listed as the cases. We can match any expressions that aretrue.It's probably not considered 'best' practice as it doesn't adhere to the irrational dogma of the high priests of 'clean' code
There's literally no need for the last sentence of your comment.
As to why it's considered not a best practice: while you could definitely use a screwdriver as a hammer, that's not the intended use. It's an incredibly smart way of using the
switchstatement but it's not the way it's intended to be used and as such is harder for people to understand.If we continually write code catering to the lowest common denominator of understanding, developers will never learn all about how the languages really work - denying them the chance to improve their knowledge.
I'm a firm believer in increasing real understanding of languages. We should never tell developers they 'must' do this, that, or the other - rather, we should let them learn real understanding of how stuff works... and then - armed with that knowledge they can decide how best they can utilise the language.
Showing them something that challenges their understanding of a language feature can only benefit them, by gaining a fuller understanding
This isn't about catering to the lowest common denominator, though. This is about writing clever code that has no reason being clever. It doesn't add to a person's understanding of how the language works because, like I said, it's telling someone to use a screwdriver as a hammer. The entire premise of the
switchstatement is to compare the expression to the cases.Your code works, I'm not arguing that, just like you could easily hammer away at a nail using a screw driver but at what cost?
Which is precisely what my example is doing. Yes, it looks different to most examples of switch statements, but it's really no different - just comparing expression with expression
Gentleman gentleman, there is a third way.
(I hope you don't find the self-promoted library distasteful - I link to others at the bottom of this very short article, and of course reference the TC39 spec for pattern-matching.)
By the way, I've found that even though
switch (true) { ... }not so common, the reaction I usually see from those learning it for the first time is "Oh wow, you can do that?". There's just not a lot of friction to understanding it.... for certain interpretations of 'precisely':
switch(true) { case f(x): ...}is effectively, undeniably comparingtrueto a number of predicates.It is effectively, undeniably not comparing a value unknown at design time to one of several, distinct, possibilities, all known at design time.
Proper understanding of the language would lead to the realization that this is the opposite of what
switchis intended for.When any developer, whatever their programming language, sees a
switch, they will rightfully expect an enumeration of non-overlapping cases. This assumption allows them to effectively communicate intent.Their surprise will lead to misunderstandings, lost time, bugs, everything the one paying for the code does not want.
We should distinguish 'understanding of languages' and 'understanding what the runtime makes of it'. If we mix these up, the latter interpretation would give us carte blanche to use whatever makes the program work and blame our colleagues for not 'understanding the inner workings'. I happily refer to Duff's device and isqrt for some examples of where this leads to; justified in some cases, but to be shunned in general.
switch(true)does not belong in production code. I will refuse to merge a pull request containing it.Of course, every language needs poetry. So allow me to step out of my dogmatic production-code mindset, and appreciate the reversal of the intended use as an form of art.
I'm not convinced that intent is so clearly carried by syntax and convention alone. Surrounding context counts for a lot, and can make or break the understanding of any chunk of isolated code. I think it's perfectly reasonable to permit out-of-usual syntax so long as you can see what's going on when zooming out a bit.
I'm also not too sure that the two C/C++ examples you gave are germane. JS doesn't have proper pointers, let alone the ability to abuse them for type-casting. It can't have interleaved syntax either.
switch (true), fall-throughs, and omittingdefault:are all naturally permitted by the spec.If you don't like them, drop an
eslintrule and they won't even make it into a PR. Incidentally, I wonder if a marvel likeInvSqrtwould even exist if we had linters back then? 🤔Yup, I'm a hoot in code-reviews... luckily, I'm normally leading them. Just call me Leonardo of the PR
Totally agree: syntax alone won't convey all your intent. Like a calligrapher can still write absolute nonsense. The point was that
switch(true)...actively hides the intent.Now that, I can appreciate: the great artist-inventor's role is to experiment with the know rules (hey someone has to do it!) and build interesting and beautiful devices, some adopted right away, others understood only after 400 years :).