4 ms·

Indeed, the comment on code formatter is weird. The point of formatters is exactly to maximize the occurrence of patterns. And the added value compared to huma

Indeed, the comment on code formatter is weird. 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.

zelphirkalt 3y ago
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.
mostlylurks 3y ago
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.

zelphirkalt 3y ago

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.

mostlylurks 3y ago

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.