I'm going to have to write a whole fucking essay explaining that automatic code formatting is bad and you're wrong if you like it, aren't I
@autonomousapps do it do it do it
@jessewilson as a matter of research shall we say, how would you summarize your issues with code formatters?
The formatting rules are dumb.
Maybe I have some code that’s got a tabular structure and I want a few lines to match up vertically.
I get it just the way I want, then the code formatter comes and throws that careful alignment away.
The IDE integration is clumsy.
I’ve got .editorconfig but the tools still disagree on unimportant stuff like how aliased imports are sorted.
I don’t want an IDE plugin for whitespace! That’s just another thing that can be slow or break.
The robot does dumb things and I’m accountable for them.
Maybe I’ve got a file with a special copyright header because it’s originally authored by somebody else.
Now I’ve got to register that file in a special build file somewhere, otherwise the robots will claim copyright on a file somebody else created.
https://github.com/cashapp/redwood/blob/3fe178c14ec112982e1f33f2a931936dae962d9d/build.gradle#L28
Suppressing a broken rule is ugly.
Maybe I want to name a function CGSizeMake() with a capital C because that’s what the iOS function I’m overloading is called.
Now I need to add a suppression annotation, introducing another wrinkle to a file that’s already too complicated.
Suppressions don’t refactor well.
Suppose I’m breaking naming rules throughout a file for a good reason. I’ve got a @file:Suppress at the top.
When I move declarations out to another file, the suppressions don’t travel with them.
Unlike automatically reforming stuff, the tool always makes me add the suppress annotations myself.
Sometimes they change the formatting rules.
It will reject code that it formatted itself yesterday!
Renovate helpfully tries to update the formatter library, and the new formatter library insists on changing a bunch of innocent files as a side-effect.
Shall I accept that the formatter now owns me and makes me do tricks for its amusement?
It messes up git blame.
The ‘introduce ktfmt’ commit message is an unwanted layer of plastic film beneath which the true authorship lies.
According to line counts, the person who introduced the formatter is now the project’s largest contributor.
It creates faux consistency in the codebase.
When I pick a table at Arby’s, I pick one that’s not covered in crumbs. It’s probably got fewer germs.
If you brush the crumbs off the table without sanitizing it, you can trick me into contracting a minor illness.
If you reformat some horrible engineering manager code into something that looks good cosmetically, I might overlook that it’s using ObjectOutputStream. Which is the JVM equivalent of contacting a minor illness.
@jessewilson @autonomousapps could this be "reformatted" into a blog post please?
@ralf @jessewilson @autonomousapps Coauthored with @jw ideally.
@rjrjr @ralf @jessewilson @autonomousapps My part is easy and boring: formatting is tool whose utility grows with the codebase and contributor size. I don't need a formatter. I know Jesse doesn't need one. Probably neither Tony nor Ralf do either. And if we're working in small codebases by ourselves or with just each other we can leave it out. Like a type system or linter or whatever else, it simply removes a class of problems that I have to think about for others code who I may not fully trust.
@jw @rjrjr @ralf @autonomousapps
Having to wait ten seconds, 5-10 times a day, just because my imports might not be sorted is what actually makes me grumpy.
I’ll report the above referenced bugs. IntelliJ’s formatter is fast, and if that’s all I need I’m happy.
@jessewilson @rjrjr @ralf @autonomousapps I started to make a Gradle plugin that used IntelliJ as a library to do code formatting. It was also very slow, and it really doesn't format enough to even be useful. Maybe that's changed in the last two years (although probably not the slowness). Kotlin and Gradle are just so slow. Especially when you start looking around at what others are doing...
(image from https://youtu.be/IroPQ150F6c)
@jw @jessewilson @rjrjr @ralf conceptually, using a single automated formatter eliminates a whole class of _conversations_ (and maybe problems), but at the implementation level I find it's not nearly so straightforward. I'm also not fully convinced at the conceptual level
I also distinguish automatic code formatting from linting. I hate* the former and value the latter