I suppose it depends on what kind of tooling you specifically are talking about, but I strongly disagree in the case of Python. When you have such an "anything goes" language, it really helps to have a tool that enforces consistent style across a large group of developers.
Unpopular opinion: I think individualism showing in code is a bad thing. Code should be textbook boring with as little personality showing as possible. This, of course, is due to my experience working in a department with ~40 developers. I work so much faster when I don't have to decipher "clever" code or somebody's personal style for how to line break their over-complicated comprehensions. It slows everybody down when there are 40 different dialects being "spoken". Homogenizing our code with linters and formatters means that any part of the codebase I jump into will look completely familiar and all I have to do is focus on the logic.
"Over-complicated comprehensions" and "linting" are mostly unrelated. As mentioned my metric on when to comment is "does this comment address anything that's objectively wrong with the code?" and for "over-complicated comprehensions" the answer is probably "yes".
I don't do much Python, but when I do I've often run in to line length "linters" for example. I (strongly) prefer to hard-wrap at 80, but if your code happens to end up at 81 or 82 then that's fine too, and sometimes even 90 or 100 is fine, depending on the context. Unconditionally "forcing" a line break by a linter is stupid and makes the code worse 99% of the time. It's stuff like this that serve little point.
And if you need to constantly tell people to hard-wrap at ~80, employing common sense, then those people are morons or assholes who should be fired. It's a simple instruction to follow. (and yes, I've worked with people like this, and they either were or should have been fired).
Actually I found that the number of linters is directly proportional to the quality of the code: the more linters, the worse it is (on average, there are also excellent projects with many linters). The first reason is that people will make their code worse just to make the linter happy, and the second reason is that I found that linters are often introduced after a number of bad devs wrote bad code, and people think a "linter" will somehow fix that. It won't: the code will still be bad, and the developers who wrote it are still writing bad code.
Linters/static analysis that catch outright mistakes should be added as much as possible by the way (e.g. "go vet": almost everything that reports is a mistake, barring some false positives). I'm a big fan of these tools. But stylistic things: meh.
To me it sounds like you’re over indexing on a specific linter tool that you don’t like. Prettier, for example, does not hard wrap. You tell it an ideal width and it will let lines exceed it or wrap early (within its bounds) to ensure that the code readability is improved when wrapping.
The real advantage of linters is that code comprehension becomes easier and authoring that code becomes simpler. The code always follows the same style in every project that team has, and everyone can configure the linter to reformat on save. It also completely removes the conversation on style from code reviews.
Haven’t you ever gotten a big PR from someone because their editor settings were different and they auto formatted a file differently than it was written before? This makes PRs a nightmare to differentiate between style and substantive changes.
The auto formatting is honestly one of the biggest productivity gains as a developer that I’ve seen. No longer do you have to ensure your code is indented when typing. A lot of times, I will even write multiple lines of code on a single line and let the formatter take over. And the end result is that my code is consistent and matches the style of all the surrounding code. It takes a cognitive burden off of everyone, when writing the code and when reading it (PR or otherwise).
> Haven’t you ever gotten a big PR from someone because their editor settings were different and they auto formatted a file differently than it was written before? This makes PRs a nightmare to differentiate between style and substantive changes.
I immediately reject those PRs. If your editor can’t format only changed lines you need a better editor. If you’re working on a task, changed lines should only be for what is necessary to implement it - nothing else.
You're argueing something completely different. I never mentioned anything about autoformatters.
That said, any autoformatter will need to strike a careful balance or it will produce nonsense: too little enforcement makes the tool useless, and too much will just crapify things. gofmt mostly gets it right, but I've never been able to get clang-format to produce something reasonable. I don't know about Python, as I don't do much Python.
I wouldn’t say they’re arguing something completely different. A large subset of linting rules are by nature purely formatting rules. You can enforce line length with either prettier or a linter and both can auto fix the issue.
Because of this things like [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier) exist to ensure conflicting eslint formatting rules are disabled if they can be handled by prettier.
> You can enforce line length with either prettier or a linter and both can auto fix the issue.
It's not about whether it's automatic or not, it's about the code being worse (that is: harder to read). Breaking lines because it's 1 character over some arbitrary limit is almost always bad, whether it's automatic or manual.
A human ever thinking about where to break a line is bad. Let the computers do that, in one standard way for a project, and never think or talk about it again. The amount of time people have wasted on trivia like this over the decades is astronomical. It doesn't matter what the answer is, pick one, make it automatic, and move on.
Both things are true. It's worth arguing about so infrequently it's never worth thinking about whether it's worth arguing about, let alone argue about; but automated tools still make decisions far worse than any human would make sometimes.
There's human factors reasons for e.g. web sites optimised for reading not using the full width of a modern screen though (including ones where the unused side space is not, in fact, filled with gunk but left empty with the text down the centre e.g. 40% of the screen even so), and it goes for code as well - the hardware might have changed but the liveware hasn't.
132 is fairly reasonable but I can still skim-read 80 column code noticeably faster (especially when I'm looking at a side-by-side diff).
You're welcome to have different preferences, of course, but I came to using 80 columns from having previously written much wider code myself - and the width of the -screen- I was using had nothing to do with my choice to switch.
But if all code looks like the same homogenized paste, then all expressivity from code is lost. Which is fine if you want to write the 68th CRUD app with developers who don't want to work on it, but seriously, it does wonders to productivity when everyone enjoys the tools they work with and the work itself. Forcing everyone to satisfy tools/code reviewers just kills all the joy from programming, so you get everyone to be mediocre.
But if all pipework looks like the same homogenized paste, then all expressivity from plumbing is lost. Which is fine if you want to install the 68th kitchen sink with plumbers who don't want to work on it, but seriously, it does wonders to productivity when everyone enjoys the tools they work with and the work itself. Forcing everyone to satisfy standards/inspectors just kills all the joy from plumbing, so you get everyone to be mediocre.
// fires the missiles.
// Spongebob case (and extra underscores) makes it hard to accidentally type.
void FiRE___MIsSiLeS(); // !!!!
// be careful!
void fire_missives(); // posts a witty tweet
After code review:
void fire_missiles(); // fires the missiles
void fire_missives(); // posts a witty tweet
...until someone has to work on someone else's overly clever "masterpiece". It's not so black and white and a tricky thing to get right and almost impossible to satisfy everyone's needs.
In an ideal world, developers care more about how their program works more than how it is written. But ya, unfortunately most people are working on applications they don't care about, so they get overly creative with code and tools.
Almost always, the "overly clever "masterpiece"" is unreadable because there is no proper documentation, not because the program itself is horrible. If you can't understand it because the writer didn't document it properly, shout at them for the lack of documentation, not for the unorthodox code style....
Workaday code should be documented so another developer can skim it in n minutes rather than spend n3 close-reading it.
If workaday code needs documentation for other developers to understand it to begin with, it needs a rewrite. Even if it runs great as code, people aren't computers and it needs to communicate it's purpose to both. Finding a showstopping bug under pressure in code like that is enough to make you want to put pencils though your eyes.
Others also seem confused— it clearly wasn't the best wording. Maybe the usage is more common in my regional dialect or something.
'Workaday' technically has two definitions: the first is something work related, and the second is something ordinary, common, or routine. Both definitions carry connotations of the other though. In this context, I'm referring to the everyday code that we write to solve most problems. I'd juxtapose this with unusual code working around really weird constraints or making up for a fundamental shortcoming or bug in a language or critical library which might require janky counterintuitive code.
I'm not saying not to document nor did I say that the program itself is inherently horrible. Often we're working on one problem which will having us jumping into a function we've never seen before. If I have suddenly switch context to read a bunch of documentation to understand someone's "creative" coding style, I will not be happy. Agree to disagree, it seems!
I do think this is a real consideration. In my view, the best case is that the code is as boring as possible, in service to an exciting project. Or to flip it around, I think the desire to find enjoyment in the code itself is more pronounced when working on boring projects.
Our python tooling enforces an 80 character limit and every time I run into it I make my code worse in some way to comply. Usually it's just less descriptive variable names, sometimes it's less readable autoformat. I've given up fighting it, just let it stink things up.
I can only agree with this if the lint rules are paired with 100% automatic reformatting, and not simply a lint rule that rejects the changes. It's a huge waste of time to force the author to go back and manually fix line lengths to meet someone's arbitrary preference for how long a line should be. Line length is clearly a preference and forcing everyone to conform to a single standard doesn't solve legibility.
The language should make line breaking obvious or automatic. IMO, The fact that it's an issue at all seems like a weakness in Python's syntax. Compared to the languages dominated by curly braces and the lisps with their parenthesis. Python saves my pinky fingers from typing braces and parenthesis but it demands more attention to the placement of line-breaks. Combine that with very short line-length standards and it leads to significant annoyance.
Python is a shit show, absolutely. However, all you have to do to get around things like arbitrary line lengths making code objectively worse is to either, 1) increase the line length something more reasonable/modern, like 100 or even 120, or, 2) agree as an organization which lint rules to disable as part of your org's official "style guide".
> Line length is clearly a preference and forcing everyone to conform to a single standard doesn't solve legibility.
I fully disagree here. Enforcing 80 characters is way too short for any reasonably complex code and leads to exactly the issue you're complaining about: tools doing automatic line breaking which make the code worse, AND/OR developers making their code more golfy in order to fit inside the line length limit whenever possible.
What you're arguing for (individual developers taking responsibility for their own line breaking style) would only work if every developer cared about such things, and now you have business/product complaining to project managers about how much time we're wasting formatting our own code by hand instead of letting automation remove that variable from the equation.
Again, all of these opinions are with the perspective of working with dozens of developers on a very large and complex codebase. If I personally disagree with somebody's "style" for line breaking, and I happen to find myself working in their code, what am I supposed to do if I personally find their code more difficult to read? Do I do re-work to make the format align with how I best read code? What happens when the original author comes back?
Developer ego is a huge problem. Automated formatting and linting help to reduce that problem.
EDIT: I was actually responding more to arp242... whoops
> Enforcing 80 characters is way too short for any reasonably complex code
Making it a hard requirement is a bad idea, making it 'required unless you can give a really good reason' (and notice that arp242 made clear that lengthening some lines a bit was a perfectly reasonable thing to do) is usually* workable.
My usual coding style tends to fairly naturally fit into 80 columns, -especially- in the case of complex code because that tends to get broken up vertically for clarity, and an '80 columns unless you have a good reason' limit seems to work out fine for e.g. PostgreSQL whose source code I personally find -extremely- readable.
I do agree that a lot of the time having some sort of autoformatter that everybody runs is a net win, especially since with a little practice you can usually predict what the autoformatter is going to do and code such that the output is decently clear to read as well as consistent with the rest of the codebase.
(*) Enterprise java style codebases where every identifier name is a miniature essay less so.
Unpopular opinion: I think individualism showing in code is a bad thing. Code should be textbook boring with as little personality showing as possible. This, of course, is due to my experience working in a department with ~40 developers. I work so much faster when I don't have to decipher "clever" code or somebody's personal style for how to line break their over-complicated comprehensions. It slows everybody down when there are 40 different dialects being "spoken". Homogenizing our code with linters and formatters means that any part of the codebase I jump into will look completely familiar and all I have to do is focus on the logic.