Formatting code should be unnecessary • Hacker News Board

Re: Formatting code should be unnecessary

#41

Post by jmward01 » Mon, Sep 08, 2025, 2:27 AM UTC

I have gotten into discussions with people about linters and code formatting standards in general and I always liken it to a work desk. If my company decided that every work desk had to be 100% generic and that every day if I put any adjustment, even to the seat height, on that desk they would reset it, I would probably think that place was hostile. Even if I could 'auto format' it back to something close every time I stepped up to the desk I would be pretty unhappy. It just wouldn't feel like mine and eventually I would be beaten into whatever style, which wasn't my own, the code came out of the repo as. Basically, linters are evil. They only work for the person that set them up.

Leave code format up to the primary owner of the file. It is pretty rare that code has more than one person that does 95% of the edits on a file so let them own the formatting. In the rare case where there are shared files with shared edits then it is ok to mandate some sort of enforced format but those are so rare that it generally isn't worth discussing. The proposed approach here ignores all the messy non-standard stuff that happens because of the margins or the rules that are very hard to build in when codifying personal coding style.

Let me have my messy desk and I'll let you have yours.

Re: Formatting code should be unnecessary

#42

Post by __MatrixMan__ » Mon, Sep 08, 2025, 2:35 AM UTC

Unison doesn't move the formatting choices further than the machine on which the code was written. The codebase only contains the AST.

Its such a cool idea, though I haven't spent much time using it in anger, so its hard to say if its a useful idea.

Re: Formatting code should be unnecessary

#43

Post by frizlab » Mon, Sep 08, 2025, 2:40 AM UTC

davetron5000 wrote: post #25

There’s also a typography element to formatting source code. The notion that all code formatting is mere personal preference isn’t true. Formatting code a certain way can help to communicate meaning and structure. This is lost when the minimal tokens are serialized and re-constituted using an automated tool. https://naildrivin5.com/blog/2013/05/17/source-code-typograp...

Yes! I’m always appalled that people cannot see that.

Re: Formatting code should be unnecessary

#44

Post by dubya » Mon, Sep 08, 2025, 2:44 AM UTC

bertil wrote: post #24

That’s essentially what black has done with Python, though.

I want to like Black (or rather, uv format), but the mandatory trailing commas weird me out, especially in function definitions. It always looks like an error to me.

Re: Formatting code should be unnecessary

#45

Post by duskwuff » Mon, Sep 08, 2025, 3:18 AM UTC

spyspy wrote: post #22

scubbo wrote: post #18

Earlier quoted context omitted.

I disagree with almost every choice made by the Go language designers, but `Gofmt's style is no one's favorite, yet gofmt is everyone's favorite` is solid. Pick a not-unreasonable standard, enforce it, and move on to more important things.

My only complaint about gofmt is that it’s not even stricter about some things.

Good news: there are tools like https://github.com/mvdan/gofumpt which fork gofmt and enforce stricter rules (while remaining invariant under gofmt).

Re: Formatting code should be unnecessary

#46

Post by pwdisswordfishz » Mon, Sep 08, 2025, 3:46 AM UTC

sublinear wrote: post #15

accelbred wrote: post #13

Earlier quoted context omitted.

What if the common intermediate encoding is text, not binary? Then grep/diff/sed all still work. If we had a formatting tool that operated solely on AST, checked in code could be in a canonical form for a given AST. Editors could then parse the AST and display the source with a different formatting of the users choice, and convert to canonical form when writing the file to disk.

Nobody wants to have to run their own formatter rules in reverse in their head just to know what to grep for. That defeats the point of formatting at all.

That's why you grep for a syntactic structure, not undifferentiated text.

Re: Formatting code should be unnecessary

#47

Post by pwdisswordfishz » Mon, Sep 08, 2025, 3:51 AM UTC

davetron5000 wrote: post #25

There’s also a typography element to formatting source code. The notion that all code formatting is mere personal preference isn’t true. Formatting code a certain way can help to communicate meaning and structure. This is lost when the minimal tokens are serialized and re-constituted using an automated tool. https://naildrivin5.com/blog/2013/05/17/source-code-typograp...

> A C argument declaration is made up of modifiers (register, const), a data type (char *), and a name (from).

Now explain a declaration like "char *argv[]"...

> We’ve also re-set the data type such that there is no space between char and * - the data type of both of these variables is “pointer to char”, so it makes more sense to put the space before the argument name, not in the middle the data type’s name (update: it should be pointed out that this only makes sense for a single declaration. A construct like char* a, b will create a pointer to char, a, and a regular char, b).

Ah, yes, the delusional C++ formatting style. At least it's nice that the update provides the explanation why it should be avoided.

Re: Formatting code should be unnecessary

#48

Post by laserbeam » Mon, Sep 08, 2025, 3:58 AM UTC

Reminds me of dion systems. A few years ago a group of devs was working on a programming environment that feels very close to what DIANA is describing.

The project is dead enough that they no longer own the TLD for the company. As far as I know, the only remnants of the project are youtube recordings of demos held at conferences.

Re: Formatting code should be unnecessary

#49

Post by Buttons840 » Mon, Sep 08, 2025, 3:58 AM UTC

jsharpe wrote: post #7

kelseyfrog wrote: post #2

The tradeoff here is not being able to use a universal set of tooling to interact with source files. Anything but text makes grep, diff, sed, and version control less effective. You end up locked into specialized tools, formats, or IDE extensions, while the Unix philosophy thrives on composability with plain text. There's a scissor that cuts through the formatting debate: If initial space width was configurable in th…

Exactly. This idea comes up time and time again, but the cost/benefit just doesn't make sense at all. You're adding an unbelievable amount of complex tooling just to avoid running a simple formatter. The goal of having every developer viewing the code with their own preferences just isn't that important. On every team I've been on, we just use a standard style guide, enforced by formatter, and while not everyone agre…

> Arguing and obsessing about code formatting is simply useless bikeshedding.

Unless it's an accessibility issue, and it is an accessibility issue sometimes.

Re: Formatting code should be unnecessary

#50

Post by automatoney » Mon, Sep 08, 2025, 4:02 AM UTC

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.