Personally, I rely a lot on autoformatters ran on save. It frees my mind completely from thinking about formatting, I can write ugly one-liners that get immediately beautified and I have an almost-immediate feedback for syntax errors (it doesn't autoformat => I made a syntax error somewhere)
This was something I wasn't really expecting when I started working on prettier. It was a strong selling point when people adopted it within Facebook.
I still can't believe that it only took a year between the first commit of prettier and 100% of Facebook massive codebase to be completely formatted using prettier.
Prettier is also growing extremely quickly in open source. It's now at 3.7 million downloads a week, compared to 6 million for React.
Even if there were no other advantages to Prettier, I would use it for this. It seems barbaric to write in languages now that don’t have something similar happening on save.
That latter point is how I do a lot of my syntax-related bug finding with Emacs: press C-x h Tab, look for where the indentation starts to look unexpectedly wonky, fix the issue that caused it, repeat.
Same here. This is so powerful. I absolutely love python, but this is one thing it doesn't allow. On the other when working in say Rust, I can express my thought in a line or 2 straight from brain to keyboard without having to care about any formatting, hit autoformatter and also typically get an immediate feedback about basic syntax.
When writing in a language that can be auto formatted, it is a huge cognitive overload removed from my shoulders, like having a copilot.
My team just converted to `black`. I find it shockingly bad. I does format code legally according to its rules, but the result is often absolute trash from a human readability standpoint.
I’m fascinated by this response: Black has been the first Python autoformatter I have had that problem with and felt comfortable enabling as a pre-commit / CI check.
Do you have any examples of things which were so bad? The team has been pretty response for the handful of things which I reported.
Black will mindlessly split long lines into shorter, and my coworkers will just leave them as is. The results are eye bleedingly awful.
I hope most black proponents expect people to look at the generated code and change things until it looks decent?
Of course this problem is inherent in a tool that is autoformatting rather than warning, and seems to me to indicate a mentality that code is meant to be read by computers, not humans.
I think some of this is just that you have strong personal opinions which are somewhat out of the norm. I have Black split long lines but the results are never what I’d call awful and I’d increasingly class that as a code-smell indicator since the cases where I haven’t been happy with the results were generally unnecessarily complex lines which could be split to be more readable.
I would also flip your last sentence completely: computers don’t have problems reading code of any style. Auto-formatting is so humans don’t burn time adjusting to different styles or, worse, failing to parse them the same way as a compiler.
The split of the long lines aren't bad, but they are also bad because the long lines are inherently too complex.
Of course some times our broken up lines are too complex, and should ideally be restructured, but...
1. The mechanical way Black does it is rarely the best way to decomplexify things.
2. Often the long line wasn't complex at all. It just contained a simple but long string. Line length is a weak measure of code complexity, but as a dumb script, it's all Black can use.
That said, my main beef is really with the 88 char line length. If it was 120 or 140, I wouldn't like Black either, but I'd only be kinda annoyed. Coupled with 4 char indentations, 88 s an absurdly small space to fit code in, when we have the biggest screens in history. It's an incomprehensible madness to me.
Not sure what your final section says. I hope it's not that humans should learn to read code just like computers do?
To me, one of the most important quotes about our job is this:
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
I think the point is that the valid python syntax is potentially a limitation on any autoformatting tool. Like, suppose you were writing in C. You might well write this:
if(x);else if(y){if(z);else;}
and clang-format would turn it into this:
if(x) {
} else if(y) {
if(z) {
} else {
}
}
But the equivalent in Python has to be correctly indented to be interpreted properly, because you need to distinguish these two cases:
if x: pass if x: pass
elif y: elif y:
if x: pass if x: pass
else: pass else: pass
This is sort-of not unreasonable, because of course code has to be syntactically correct for the autoformatter to do its thing, and if you're working in Python, these are the syntax rules. So, what can you do?
But suppose you'd come to find it valuable to be able to stuff all your code on one line and have the autoformatter sort it out: you might then find the Python syntax a backwards step by comparison, rather than an improvement. I think this is the claim that's being made, and no more.
