They're not very important if you're the only developer on your team.
If you're working with others, though, then it becomes very important. I don't think I'm being entirely hyperbolic when I say that inconsistent or poorly-chosen formatting rules are the death of 1,000 cuts for a team's productivity.
There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a noisy code review that takes longer to read, or makes it harder for reviewers to discern the real changes from the formatting junk. There's a tiny but existent cost when excess delta makes it harder to gitblame. There's a tiny but existent cost when people have to stop and think about how to format their code manually. Or when they have to stop and debate formatting. Or when they read someone else's code slightly more slowly because different formatting rules make it harder for them to skim it or rely on pattern recognition instead of careful reading to understand its structure.
All those tiny little costs add up to something that's not so tiny. And it's so easy to make it just disappear, for the low low cost of swallowing one's pride, by simply adopting an opinionated autoformatter.
> There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a noisy code review that takes longer to read, or makes it harder for reviewers to discern the real changes from the formatting junk. There's a tiny but existent cost when excess delta makes it harder to gitblame.
Don't reformat code you didn't otherwise touch. That's just common sense. Common sense autoformatters lack.
> There's a tiny but existent cost when people have to stop and think about how to format their code manually.
I rarely think about how I format my code. When I do, it's because the code is hard to format in a readable way, in which case an autoformatter will produce garbage.
> Or when they have to stop and debate formatting.
"Doctor, it hurts when I do this."
> Or when they read someone else's code slightly more slowly because different formatting rules make it harder for them to skim it or rely on pattern recognition instead of careful reading to understand its structure.
Neglible. To the contrary, different formatting reminds you that you did not write this code and you should read it more carefully because you can't expect its creator to think the way you do.
I've never been able to wrap my head around people having strong opinions on style issues. I'll defer to whoever cares the most on the team and then just do that. When I look at the problems in code bases, rarely has "slightly inconsistent formatting" been at the top of the list.
Because you don't know if they've done the trick. That's why natural language is padded with extra words to add context and help rule out misunderstandings. The grammatical rules of agreement are one mechanism to do this.
And you can see the phenomenon of over-abbreviation by reading a few debates on twitter and repeatedly seeing, "how can you not understand what I tweeted?!"
I remove semicolons from JS b/c I feel like they are a bit of a hack. Except where it's required by the language (for loops, which are becoming less used quite rapidly), your code generally shouldn't be so complex as to require semicolons for readability.
Having said that, I've been introducing a lot more colons, since I use TypeScript.
I was referring to punctuation that is, in some way, actually necessary. No one ends their lines with semicolons in python although it's valid. The rules when the interpreter will "insert" them are obvious. Not so in Javascript.
Neither is very important, though. It's just formatting and your code will run the same regardless.