Comment by perrygeo | Hacker News Reader

Comment by perrygeo | Hacker News Reader

Parent Full thread

> convey meaning with subtle code style differences

Why? This is exactly why we need autoformatters :-) if you're on a team, you should be conveying meaning with variable names, comments, and structure. If it doesn't show up in the syntax tree, it doesn't have meaning. Consistency always wins because it elevates everyone's ability to read the code.

There's more to it than the social aspect though: putting effort into manually moving around characters in a text editor is not the best use of mental bandwidth. My experience (and that of many I know) is that formatters help you code faster with less bugs by letting you focus on the higher-level structure of the problem NOT on the minutiae of where each punctuation mark should live. If your code is syntactically correct, the autoformatter will make it look "right" and you don't have to think about consistent formatting at all. If it's not syntactically correct, you set your editor to autoformat on save and you get immediate feedback. So it's not just about consistency, it's also a productivity aid.

I understand having strong opinions about the "right" code style. Personally, I dislike the double quotes in black. So I type single quotes and let black do its thing on save. What I type does not need to be what I commit (so long as they both compile to the same AST)! I don't want to waste time debating formatting details in a PR, and I certainly don't want to interrupt my coding flow to manually perform the labor of shuffling ascii chars around when there is fully automated solution. I can't think of a single scenario where my personal style preference would outweigh the significant advantages I've seen from autoformatters.

> If it doesn't show up in the syntax tree, it doesn't have meaning.

Why did you use paragraphs to write your comment then? People read the code thats written.

Auto formatters support paragraphs, but they don't support I'm going to give this paragraph 2 blank lines because it's particularly important/complicated/blah.

Oh interesting thanks! I couldn't find it in the docs before

Yeah, I don't think it's mentioned because it feels like supporting spaces between words, I’d guess. Just so fundamental a functionality it's assumed.

Typographic standards typically don't, either. Fortunately, there's more than one way to convey emphasis.

Also, single functions that are long enough to contain something analogous to paragraphs are arguably not Pythonic in the first place.

For paragraph I just mean a series of 1 or more lines separated by a blank line vs no blank lines.

Are there two blank lines between these parts of the code for a reason or did the person who wrote this code make a mistake?

If that part of the code is special for whatever reason, add a comment saying why.

I think the argument is not that structure should be dispensed, or that it doesn't matter, rather that a given style convention is fungible, and we should probably all just pick something good enough and get on with it, because the code will execute regardless of whether we use " or ' around our strings.

Spend some time considering the language standards, but then ship it for god's sake.

See also from Peter Norvig[0]:

* Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.

* Have the good sense to get off the language standardization effort as quickly as possible.

[0]:https://www.norvig.com/21-days.html

I actually had this formatter thing happen at work. We have code that generates more python code. Now the quotes are changed and we need escapes because a rule it being applied. Escapes are harder to read and look messier.

> So I type single quotes and let black do its thing on save.

It is the one small grip, I have with black. C&P for example some string-indexed dict element as argument into a f-string sometimes produces duplicate double quotes if it gets into black's hands beforehand. But in the end, black outweights all these minor things. This particular issue also is probably better considered as a tooling task for editors, IDEs etc.

Reply on news.ycombinator.com