Automating formatting for official D repos

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed Jan 24 01:11:00 UTC 2024


On Tuesday, January 23, 2024 5:49:28 PM MST Meta via Digitalmars-d wrote:
> On Monday, 22 January 2024 at 23:10:06 UTC, Jonathan M Davis
>
> wrote:
> > Please, no. Code formatters consistently make code look like
> > garbage. Some flexbility is needed if we want code to actually
> > look nice.
> >
> > - Jonathan M Davis
>
> For a large project like this with many contributors, consistency
> is more important than personal aesthetic preferences.

My complaint isn't about that. My complaint is that when you have a
formatter do it, the code always ends up looking ugly no matter the rules
used, because it's too inflexible about it. We already have a style guide
(and have had for years), and it's fairly straightforward. When a human
follows it, there is some flexibility, because the guide has some
flexibility, and so the human can make intelligent decisions about things
like line breaks, whereas the formatter is going to be dumb about it and
apply a much more exact set of rules that then result in things like
breaking up the code in places which make the code harder to read.

Formatters always result in terrible looking code. Obviously, if you prefer
the target coding style, it's going to look better than if you don't, but
computers have zero aesthetics, so the results always have issues. Of
course, the advantage is that you can then just tell folks to use the
formatter (or automate the process), and then there are no arguments over
the result (which is obviously which folks like to use formatters), but the
result is always terrible, which is why I'd much prefer that any project
that I work on not use a formatter. At least if the process involves a bot
telling you that the code failed some style rule, the human can fix it in an
intelligent manner, whereas the formatter is just going to uglify the code
in the process.

- Jonathan M Davis





More information about the Digitalmars-d mailing list