The rule n°1 is very strange, if switch & continue exists it's for a reason, using them for what they was thought for is the best way of coding; a top layer for conditions. Yes you can instead use if-else because of .. security ?😅 But maybe you can use if only & not else because of security too ? 🥴
The 9.1 do not use reference, ouch, why ? same as above use them for what they are best for, if you only use copy variables what about scalability for very large element like some json parsed result ? Furthermore javascript for eg use reference only for object elements ..😄
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
The fact that a feature exists in a language doesn't mean it's a feature worth using. These languages are designed by mortals and often inherit patterns and ideas from previous (and flawed) languages.
JavaScript, while beloved, was originally designed in a hurry and is famous for having "bad parts" which experienced developers not only avoid using but purposefully don't teach to newbies.
You say we should use these features for what they are best for. I agree that we should certainly not abuse any language feature, but the point here is that there are almost always better ways to solve the problems these features address. By "better" I mean "easier for you and others to understand next year" and "offering fewer places for bugs to hide."
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
The fact that a feature exists in a language doesn't mean it's a feature worth using. These languages are designed by mortals and often inherit patterns and ideas from previous (and flawed) languages.
JavaScript, while beloved, was originally designed in a hurry and is famous for having "bad parts" which experienced developers not only avoid using but purposefully don't teach to newbies.
You say we should use these features for what they are best for. I agree that we should certainly not abuse any language feature, but the point here is that there are almost always better ways to solve the problems these features address. By "better" I mean "easier for you and others to understand next year" and "offering fewer places for bugs to hide."