Another blind gospel: braces around if-statements imply that people don't understand what braces do (they turn a group of statements into a single statement). So rules like "always put braces around the body of your if-statement" get it backwards, it'd be like wrapping every value in an array, because maybe you'll want more than one of them, someday.
This brings us to the the three-brace rule: if you're going to make me put one brace where I don't need it, then I'm going to add two more.
functionwow(arg){{{if(arg==="dog"){{{return"LOVELY"}}}elseif(arg==="cat"){{{return"CUTE"}}}else{{{return"gimme an animal"}}}}}}console.log(wow("cat"))// => CUTEconsole.log(wow("dog"))// => LOVELYconsole.log(wow("hat-log"))// => gimme an animal
Now, in people's defense, JavaScript's syntax is terrible, it's absurd that this works (when it would be so much more useful to have toplevel objects), and given that it works, it's absurd that you can't drop the braces around function bodies.
And the other super obnoxious mostly un-understood rule: littering semicolons all over the code. Literally after every line that they can, rather than before the ones that cause the problems. It's especially misguided b/c it masks the actual problem lines, and it gives a false implication that omitting the semicolon would mean it continues on the next line. But that isn't true, JS doesn't need a semicolon to terminate the line, only to terminate it early. The reason you stick them at the end is b/c sometimes the next line says "oh hey... Imma tag along with the previous line", so with this dumb rule, every line has to guard against an aggressive next line.
log=text=>{console.log("logged: "+text);returnlog}log("loggin stuffs")// and now for some math(2+2)(3+3)
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I agree it's interesting that you can't drop the braces around function bodies (which hadn't occurred to me before) but the example in the post, of where else if ... is actually else { if ... } seems obvious. Isn't that behaving exactly how it's written, and isn't that how everyone would expect it to work if they'd never seen the language before?
Passionate with code... In love with Web Design, Videogames, Books and Jazz music.Years of experience in "document composition" and a Front-End Developer wannabe (since years)
It's not.
Because we're always encouraged to use {} in some ways, and we learn by memory to use those, without knowing the why.
During the first approach to a language, you cannot be so deeply analytic, because you've to trust the rules, or you will never go on.
After the totally beginner phase, you should start to ask yourself the why.
Passionate with code... In love with Web Design, Videogames, Books and Jazz music.Years of experience in "document composition" and a Front-End Developer wannabe (since years)
Passionate with code... In love with Web Design, Videogames, Books and Jazz music.Years of experience in "document composition" and a Front-End Developer wannabe (since years)
Now, in people's defense, JavaScript's syntax is terrible, it's absurd that this works (when it would be so much more useful to have toplevel objects), and given that it works, it's absurd that you can't drop the braces around function bodies.
I know what you're talking about.
But do we know, why It's still working?
It's working because of blocks.
You're creating blocks, inside blocks... inside blocks.
That's important in JS, because of the lexical-scope.
I'm not saying that's ok ... I'm just saying that in JS It works like that, not just because It's bad
I'd expect three times. The function foo(x) would receive the next syntactic element as its body, which is console.log(x). Not because of indentation, but because it's the next expression. If you wanted more than one expression, you would use the braces to make a block, which would group the multiple expressions into one. Then it would be consistent with the way we use blocks on if statements.
Another blind gospel: braces around if-statements imply that people don't understand what braces do (they turn a group of statements into a single statement). So rules like "always put braces around the body of your if-statement" get it backwards, it'd be like wrapping every value in an array, because maybe you'll want more than one of them, someday.
This brings us to the the three-brace rule: if you're going to make me put one brace where I don't need it, then I'm going to add two more.
Now, in people's defense, JavaScript's syntax is terrible, it's absurd that this works (when it would be so much more useful to have toplevel objects), and given that it works, it's absurd that you can't drop the braces around function bodies.
And the other super obnoxious mostly un-understood rule: littering semicolons all over the code. Literally after every line that they can, rather than before the ones that cause the problems. It's especially misguided b/c it masks the actual problem lines, and it gives a false implication that omitting the semicolon would mean it continues on the next line. But that isn't true, JS doesn't need a semicolon to terminate the line, only to terminate it early. The reason you stick them at the end is b/c sometimes the next line says "oh hey... Imma tag along with the previous line", so with this dumb rule, every line has to guard against an aggressive next line.
I agree it's interesting that you can't drop the braces around function bodies (which hadn't occurred to me before) but the example in the post, of where
else if ...is actuallyelse { if ... }seems obvious. Isn't that behaving exactly how it's written, and isn't that how everyone would expect it to work if they'd never seen the language before?It's not.
Because we're always encouraged to use
{}in some ways, and we learn by memory to use those, without knowing the why.During the first approach to a language, you cannot be so deeply analytic, because you've to trust the rules, or you will never go on.
After the totally beginner phase, you should start to ask yourself the why.
Have you ever encountered a bug caused by missing parentheses? Being consistent improves code readability and makes it easier to identify bugs.
It's not about... DON'T USE PARENTHESES :D It's all about know the why of parentheses
This proves that grammar in JS is a joke!
I know what you're talking about.
But do we know, why It's still working?
It's working because of blocks.
You're creating blocks, inside blocks... inside blocks.
That's important in JS, because of the lexical-scope.
I'm not saying that's ok ... I'm just saying that in JS It works like that, not just because It's bad
Apparently I didn't use the word
blockin there, but yes, I understand this :)If you want to be really irritated with JS, figure out what's going on with these examples (hint)
Without braces, how would the interpreter / a fellow developer know where the function ends? If you write
then how often are you expecting to see Hello logged? Three times? Four times? Zero times? An unbounded number of times due to recursion?
Some languages use whitespace or
end, but I find the braces to be more readable and less error prone.I'd expect three times. The
function foo(x)would receive the next syntactic element as its body, which isconsole.log(x). Not because of indentation, but because it's the next expression. If you wanted more than one expression, you would use the braces to make a block, which would group the multiple expressions into one. Then it would be consistent with the way we use blocks on if statements.Oh, also note that this is how fat arrows work:
Python developer disagrees. 🐍🐍🐍