I have to disagree with the not using the source code formatters bit though.
More trivially, you can improve the source code formatters to accept the example provided as legitimate. In fact, it can be setup to automatically format other similar patterns that way itself.
Yes humans are good at patterns but there’s only so many patterns you can form while writing code, and the heuristics involved while deciding what pattern to use can almost certainly be encoded fairly easily.
But even if we assume that this isn’t possible, a formatted is still very valuable for the simple reason that others may not follow the same patterns as you, or may not follow patterns. Someone else formatting the code differently may rub you the wrong way, and the only way to resolve that is the worst type of code formatting bike-shedding.
And if you don’t agree and both of you do your own thing in different parts of the codebase, well, you’re not following a pattern and you’ve lost the benefits indicated about following patterns.
One can distinguish between patterns that should be forced (e.g. brace placement) and patterns that should remain up to the programmer (e.g. whether a particular “if” statement may be single-line). Meaning, using a formatter can still allow the same code to be formatted in different ways. (Where to insert blank lines for visual structuring is maybe the most obvious example. You wouldn’t want to automate that.) It’s thus a spectrum rather than an all-out black and white.
> Where to insert blank lines for visual structuring is maybe the most obvious example. You wouldn’t want to automate that
In general, I agree, but I actually had some success doing that in a couple cases with custom linter rules.
Some tests were becoming unreadable because of lack of separation between sections, so I started enforcing. We also enforced at least two more spaces in between setup/execute/verify sections, where expectations could only show up in the third section.
This can be annoying if you use a different style, but all our tests followed the same patterns, so it made sense to enforce.
Formatters can also readily spot and preserve patterns if you want them. You can shape the cost function to value patterns.
I suspect Walter formed this opinion when they were much worse.
Also formatters have enormous benefit when you have lots of people in the same project. It almost doesn't even matter what the format is as long as it's efficient IMO.
Exactly. Walter Bright also used to be a lone hero - he isn't anymore. But some habits stick of course. Also the languages he writes in might not have the best formatters.
I am old enough to have experienced the not so good formatters (in mainstream languages) and wasn't a fan. But after working with really great formatters, its such a benefit I don't like to go without it anymore.
The quality of the formatter is extremely important. Using a bad formatter is such a bad experience that I would agree it may be better to not use it... but modern languages have this problem mostly solved (not so sure about D)... the example in the post would still be broken up in multiple lines because almost all formatters will avoid having multiple "statements" in a single line, for good reason.
But as with any tool: you can probably improve it, for example, to keep this exact "pattern" if you really like it... I wonder if there are formatters that are powerful enough to allow this sort of customization.
I can see his point. I'm also perfectly fine with programming without a linter/formatter for personal projects or bigger projects where quality is more important than speed. The code doesn't look worse. In fact it might end up better.
But for corporate teams, doing web dev? It is definitely necessary, unless you want to spend days reviewing trivialities, or you're ok with the code looking like a patchwork quilt of styles.
The point of formatters is exactly to maximize the occurrence of patterns. And the added value compared to humans is that you know for sure there will be no mistake (or at least much much less), and so this is something you can rely on.
The main complaint is that formatters do not (alwaysà follow your favorite pattern. But I much prefer to learn the many patterns that the formatter gives to me for free, than to have to fight to have mine adopted.
I am finding myself often fighting an overly naive code formatter that is "opinionated" and has not much of a way of configuring it, except for maybe line length.
It is so naive, that I cannot make it keep long log lines but break other long line. It has no way of distinguishing those. So I might have 5 lines of log over 2 lines of code, just because of that. So logs get more screen real estate than the actual code and that is so silly.
Then it will undo my own line breaking of procedure calls, if the call could theoretically fit onto the max line length. Only when I add a trailing comma after the last argument I can prevent it from doing its silly changes, that only serve to reduce readability.
It will also complain about long comment lines. So when I have a long line starting with "# TODO:" I would like to keep in 1 line, because when I search for TODO, I will see all of it in the search result.
Most formatters are annoyingly naive and format code so that it becomes less readable than what a capable developer, who cares about readability will output.
Code formatters collapse a variety of different patterns, which could be intentional emphasizations of various aspects of the code, as is the case in the example shown in the article, into a single pattern, which eliminates that information. You might call this a maximization of the pattern that the formatter happens to produce, but as a result, the pattern becomes useless, because it communicates nothing.
The same applies equally to any human programmer that formats their code as consistently as a formatter would.
> Someone else formatting the code differently may rub you the wrong way, and the only way to resolve that is the worst type of code formatting bike-shedding.
True. Your team would just have to select a manager who decides.
I have to disagree with the not using the source code formatters bit though.
More trivially, you can improve the source code formatters to accept the example provided as legitimate. In fact, it can be setup to automatically format other similar patterns that way itself.
Yes humans are good at patterns but there’s only so many patterns you can form while writing code, and the heuristics involved while deciding what pattern to use can almost certainly be encoded fairly easily.
But even if we assume that this isn’t possible, a formatted is still very valuable for the simple reason that others may not follow the same patterns as you, or may not follow patterns. Someone else formatting the code differently may rub you the wrong way, and the only way to resolve that is the worst type of code formatting bike-shedding.
And if you don’t agree and both of you do your own thing in different parts of the codebase, well, you’re not following a pattern and you’ve lost the benefits indicated about following patterns.