News for hackers. Stuff that matters.
Re:Black – Uncompromising Python code formatter by amelius on Friday May 17, 2019 @12:34PM (#19941166)
> Having a standard is more important than the standard being excellent.

Neither is very important, though. It's just formatting and your code will run the same regardless.

Re:Black – Uncompromising Python code formatter by bunderbunder on Friday May 17, 2019 @12:45PM (#19941284)
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.

Re:Black – Uncompromising Python code formatter by anoncake on Friday May 17, 2019 @04:13PM (#19943129)
> 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.

Re:Black – Uncompromising Python code formatter by goostavos on Friday May 17, 2019 @12:52PM (#19941356)
A kindred spirit.

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.

Re:Black – Uncompromising Python code formatter by adossi on Friday May 17, 2019 @12:40PM (#19941225)
You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.
Re:Black – Uncompromising Python code formatter by awinder on Friday May 17, 2019 @12:48PM (#19941320)
Why use many word when few word do trick
Re:Black – Uncompromising Python code formatter by ben509 on Friday May 17, 2019 @01:34PM (#19941759)
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?!"

Re:Black – Uncompromising Python code formatter by gooseserbus on Friday May 17, 2019 @01:57PM (#19941976)
FYI you're replying to a joke from The Office (US) https://www.youtube.com/watch?v=_K-L9uhsBLM
Re:Black – Uncompromising Python code formatter by TeMPOraL on Friday May 17, 2019 @12:59PM (#19941422)
No, that's a completely invalid objection. Punctuation in natural languages isn't just aesthetic, it changes meaning.
Re:Black – Uncompromising Python code formatter by rcfox on Friday May 17, 2019 @03:53PM (#19942965)
Punctuation, or lack of it, can change the meaning in programming languages too.

https://medium.freecodecamp.org/codebyte-why-are-explicit-se...

Re:Black – Uncompromising Python code formatter by anoncake on Friday May 17, 2019 @04:12PM (#19943117)
Yeah, but no one would remove punctuation from a program because they think it looks nicer.

> Javascript developers

Oh, of course.

Re:Black – Uncompromising Python code formatter by JoBrad on Friday May 17, 2019 @06:59PM (#19944406)
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.

Re:Black – Uncompromising Python code formatter by anoncake on Saturday May 18, 2019 @10:12AM (#19947456)
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.
Re:Black – Uncompromising Python code formatter by andrewprock on Friday May 17, 2019 @05:03PM (#19943545)
Don't forget gofmt.
Re:Black – Uncompromising Python code formatter by firethief on Friday May 17, 2019 @01:14PM (#19941567)
That's a mostly invalid counter-objection. Technically true, but with context its usually recoverable.