Formatting code should be unnecessary • Hacker News Board

Re: Formatting code should be unnecessary

#441

Post by shepherdjerred » Mon, Sep 08, 2025, 8:54 PM UTC

craftkiller wrote: post #408

kristopolous wrote: post #240

Earlier quoted context omitted.

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

> Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool. The reformatting tools should be CI-enforced so you'll only end up with sudden massive changes like this once when you start using auto-formatters. Regardless, tell your teammates to separate out formatting changes vs logic changes into separate commits (preferably separate PRs). Since they're auto-formatters it wo…

And then setup git-ignore-revs

https://github.com/orgs/community/discussions/5033

Re: Formatting code should be unnecessary

#442

Post by kristopolous » Mon, Sep 08, 2025, 8:58 PM UTC

kristopolous wrote: post #240

AdieuToLogic wrote: post #107

Earlier quoted context omitted.

> I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwi…

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

I'll sound off more on this.

Formatters also value consistency over clarity.

I break formatting all the time for the sake of clarity.

Sometimes my comments are paragraphs long with citations and things are carefully broken down with interstitial comments and references and then the formatter fucks it all up and the linter says "wah this oblivious pedant rule isn't followed"

The problem is it doesn't treat me like an adult And I'm not in this industry for dumb Nanny tools that scold me because they don't understand things

Re: Formatting code should be unnecessary

#443

Post by GuB-42 » Mon, Sep 08, 2025, 8:59 PM UTC

And yet, judging by the number of comments, it is definitely not a solved problem :)

Re: Formatting code should be unnecessary

#444

Post by hnlmorg » Mon, Sep 08, 2025, 8:59 PM UTC

account42 wrote: post #180

hnlmorg wrote: post #111

Earlier quoted context omitted.

grep is half a century old now. If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.

We still use grep because its useful. And it's useful precisely because it doesn't depend on syntax so will work on anything text based.

grep is great. My point isn’t that we shouldn’t use it. My point is that we shouldn’t be held back by it.

Re: Formatting code should be unnecessary

#445

Post by kristopolous » Mon, Sep 08, 2025, 9:06 PM UTC

zahlman wrote: post #350

kristopolous wrote: post #240

Earlier quoted context omitted.

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

> just going through and moving shit around whenever you save a file. This only happens because the file doesn't already adhere to the rules it's implementing. These are normally highly configurable, and once your code complies to a standard, the tool prevents future code from pulling you away from that standard. > And sometimes, they actually insert bugs - string formatting errors are my favorite example. Do you hav…

I don't keep examples around to defend my stance on this, sorry.

I left out my largest critique - spacing is semantic both for the compiler and the human.

Often I police the whitespace very thoughtfully usually in code that also requires long comments for clarity.

I care deeply about maintainability and legibility of code and try to consider future human readers everywhere.

Then the formatter says "haha, fuck that!"

That's my biggest personal gripe with it. It's consistency over clarity, conformity over craft.

This all depends on what kind of code you're writing. Standard backend crud code in python with sqlalchemy? ok, pydantic with linters and formatters. But that should be written by llms these days anyways, if you're still doing it by hand you're doing it wrong.

Honestly the jobs I sign up for demand a kind of care - mostly experimental and frontier work, so I am really frustrated when I'm prevented from exercising my professional judgement and doing what I think is best due to some bureaucratic red tape.

I don't want the Wild West, I want disciplined senior engineers using professional consideration and judgement and not a bunch of onerous restricting tools assuming I don't know what I'm doing or why I'm doing it

The language designers, compiler engineers, they are the actually competent people in the room and if they allowed for the flexibility I'll side with them over some hacked out set of rewriting regexs by some kid vibe coding on GitHub

Re: Formatting code should be unnecessary

#446

Post by hnlmorg » Mon, Sep 08, 2025, 9:08 PM UTC

komali2 wrote: post #135

hnlmorg wrote: post #111

Earlier quoted context omitted.

grep is half a century old now. If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.

The things all being described are way beyond non trivial to solve, and they'd need to be solved for every language. Grep works great.

> The things all being described are way beyond non trivial to solve, and they'd need to be solved for every language.

Except it already is a solved problem.

If languages compile to a common byte code then you just need one tool. You already see examples of this with things like the IR assembly produced by LLVM, various Microsoft languages that compile to CLR, and the different languages that target JVM.

There are also already common ways to create reusable parsing rules like LSP for IDEs and treesitter.

In fact there are already grep-like utilities that are based on treesitter.

So it’s not only very possible to create language agnostic, reusable, tools; but these tools already exist and being used by a great many developers.

The problem raised in the article is that we just don’t push these concepts hard enough these days. Instead relying on outdated concepts of what source code should look like.

> Grep works great

For LF-separated lists it does. But if it worked great for structured content then we wouldn’t be having this conversation to begin with.

Re: Formatting code should be unnecessary

#447

Post by plusplusungood » Mon, Sep 08, 2025, 9:10 PM UTC

gorgoiler wrote: post #333

2muchcoffeeman wrote: post #315

Earlier quoted context omitted.

Don’t bother making decisions. Steal a standard. Vote on it once if you want to be democratic. Done forever.

Democracy, strictly speaking, would be to periodically elect the most popular formatting policy once every sensible-time-period. I’ve seen companies with such a large amount of developer churn that literally one person was left defending the status quo saying “we do X here, we voted on it once in 2019 and we’re not changing it just for new people”. 90% of the team were newcomers. (The better teams I’ve worked on main…

Ah, the infamous, but fictional, Monkey Ladder Experiment.

Re: Formatting code should be unnecessary

#448

Post by kristopolous » Mon, Sep 08, 2025, 9:14 PM UTC

triknomeister wrote: post #367

kristopolous wrote: post #240

Earlier quoted context omitted.

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

formatting on git diffs is a concept which should be embraced.

Can you go more into this?

Re: Formatting code should be unnecessary

#449

Post by aequitas » Mon, Sep 08, 2025, 9:20 PM UTC

automatoney wrote: post #50

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.

It’s very simple: format code to a standard. Preferably the language default formatting. But it must be a standard that can be auto formatted to with a tool. Now when someone doesn’t like that standard, they can auto format from that standard to one of their liking for local development and back again to the project standard for pushing to the project. This can even be done automatically with gitattributes during checkout and commit. But without strictly enforcing a autoformatable standard this is not possible and you end up with bikeshedding.

Re: Formatting code should be unnecessary

#450

Post by bogomog » Mon, Sep 08, 2025, 9:41 PM UTC

kristopolous wrote: post #445

zahlman wrote: post #350

Earlier quoted context omitted.

> just going through and moving shit around whenever you save a file. This only happens because the file doesn't already adhere to the rules it's implementing. These are normally highly configurable, and once your code complies to a standard, the tool prevents future code from pulling you away from that standard. > And sometimes, they actually insert bugs - string formatting errors are my favorite example. Do you hav…

I don't keep examples around to defend my stance on this, sorry. I left out my largest critique - spacing is semantic both for the compiler and the human. Often I police the whitespace very thoughtfully usually in code that also requires long comments for clarity. I care deeply about maintainability and legibility of code and try to consider future human readers everywhere. Then the formatter says "haha, fuck that!"…

+1 to this. Why throw away an extra dimension of expression available by choices in formatting in the name of consistency? I find it helpful to use blank lines to separate code into "paragraphs". A complex conditional may be made more readable by extra space in some places an not others. A series of single line if statements might be clearer formatted lined up vertically, like a table.