Excellent questions, the article was already too long to dive into this.
Regarding the switch issue, it's because the syntax is like this:
$foo="1";switch($foo){case"1":print("1");case"2":print("2");case"3":print("3");}// Prints "123"
Were it like this
$foo="1";switch($foo){case("1"){print("1");}case("2"){print("2");}case("3"){print("3");}}// Prints "1"
I wouldn't mind, but unfortunately it's not so the safest option is still a series of if/elseif/else.
Regarding your point on references, basically what they do is not just pass an object (which is a shared point of anchorage and can be used to retrieve subsequent data) but also make in sort that if you change the value of that object in the called function then the change bubbles up to the calling function (see the example in the article). Fortunately this feature just does not exist in Javascript so you don't have to worry about it :)
Oh no I love Python, actually it makes these rules easier to apply and also it does not have switch.
But it's about the confusing control flow rather than the syntax (which I really don't care about). Forget a break and you're toast. Stack cases and you're confusing anybody reading your code.
Ironically just a few weeks ago I read an article by Dave Cheney — the bard of Go — entitled "Clear is better than clever" that advocates for using switch instead of if / else.
His article does mention that the switch in Go does not fall-through by default and your objection to the switch — which falls-through by default (a language decision I lament) — seems to be solely based on the potential to omit a break. But his article does give other reasons for switch to be superior to if / else none of which are mentioned in your post.
Personally, I think a belief that in-all-cases either if or switch is superior to the other is simply allowing oneself to overindulge in one's own unsubstantiated opinion.
(Notice I left off else; I concur with @DoMiNeLa10 and agree with the advice of Mat Ryer: Avoid else, when you can.)
Earlier this week I refactored some if / else code to be a switch statement in PHP. I did so thoughtfully and with the sole goal of adding clarity to the code someone else wrote who is no longer involved. The code was used to take action based on number of path segments in a URL. It had one if and three (3) else ifs where each condition tested count($parts) for equality with 1, 2, 3 or 4.
I needed to add logic for 5 so I changed from if / else if / else to a using a switch so the code would not need to call count($parts) five (5) times (nor need to set a temp var) and so that the logic was clearly spelled out that it was working on a use-case that had 1 of 5 options.
Further, when formatted the code was much more readable, the breaks were obvious, and the nature of the code meant it was unlikely someone would ever add both a 6 and a 7 and forget to include a break on the 6.
My point with this anecdote is that almost all coding "rules" really should be applied with an analysis of the use-case at hand and not be considered as a pedantic absolute. Clinging to dogma really does not benefit anyone.
Unless of course we are dealing with junior programmers, and then all bets are off. :-D
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.
Excellent questions, the article was already too long to dive into this.
Regarding the
switchissue, it's because the syntax is like this:Were it like this
I wouldn't mind, but unfortunately it's not so the safest option is still a series of
if/elseif/else.Regarding your point on references, basically what they do is not just pass an object (which is a shared point of anchorage and can be used to retrieve subsequent data) but also make in sort that if you change the value of that object in the called function then the change bubbles up to the calling function (see the example in the article). Fortunately this feature just does not exist in Javascript so you don't have to worry about it :)
Based on your dislike of
switches because they do not have intermediate ending braces, my guess is you really hate Python? #justaskingOh no I love Python, actually it makes these rules easier to apply and also it does not have switch.
But it's about the confusing control flow rather than the syntax (which I really don't care about). Forget a break and you're toast. Stack cases and you're confusing anybody reading your code.
Ironically just a few weeks ago I read an article by Dave Cheney — the bard of Go — entitled "Clear is better than clever" that advocates for using
switchinstead ofif/else.His article does mention that the
switchin Go does not fall-through by default and your objection to theswitch— which falls-through by default (a language decision I lament) — seems to be solely based on the potential to omit abreak. But his article does give other reasons forswitchto be superior toif/elsenone of which are mentioned in your post.Personally, I think a belief that in-all-cases either
iforswitchis superior to the other is simply allowing oneself to overindulge in one's own unsubstantiated opinion.(Notice I left off
else; I concur with @DoMiNeLa10 and agree with the advice of Mat Ryer: Avoidelse, when you can.)Earlier this week I refactored some
if/elsecode to be aswitchstatement in PHP. I did so thoughtfully and with the sole goal of adding clarity to the code someone else wrote who is no longer involved. The code was used to take action based on number of path segments in a URL. It had oneifand three (3)else ifs where each condition testedcount($parts)for equality with1,2,3or4.I needed to add logic for
5so I changed fromif/else if/elseto a using aswitchso the code would not need to callcount($parts)five (5) times (nor need to set a temp var) and so that the logic was clearly spelled out that it was working on a use-case that had 1 of 5 options.Further, when formatted the code was much more readable, the
breaks were obvious, and the nature of the code meant it was unlikely someone would ever add both a6and a7and forget to include abreakon the6.My point with this anecdote is that almost all coding "rules" really should be applied with an analysis of the use-case at hand and not be considered as a pedantic absolute. Clinging to dogma really does not benefit anyone.
Unless of course we are dealing with junior programmers, and then all bets are off. :-D