Formatting code should be unnecessary • Hacker News Board

Re: Formatting code should be unnecessary

#21

Post by yojo » Mon, Sep 08, 2025, 12:59 AM UTC

ChrisMarshallNY wrote: post #9

I've heard that Google works [sort of] that way (don't know, myself). They have a lot of tools that allow devs to use what formatting they want, and it's made standard, during checkin. I heard this, many years ago, when we used Perforce. The Perforce consultant that we dealt with, told us this, as an example of triggers. Back then, I was told that Google was a big Perforce shop (maybe just a part of Google. I dunno).…

I can confirm that Google was using Perforce for version control extensively, at least through 2008. I think it was somehow customized, but I definitely have lingering muscle memory around “p4 sync” and “p4 submit”.

I was on an internal tools team doing distinctly unsexy LAMP-stack work, but all the documentation I ever saw talked about perforce/p4.

Re: Formatting code should be unnecessary

#22

Post by spyspy » Mon, Sep 08, 2025, 1:01 AM UTC

scubbo wrote: post #18

jsharpe wrote: post #7

Earlier quoted context omitted.

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…

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.

Re: Formatting code should be unnecessary

#23

Post by hackerbrother » Mon, Sep 08, 2025, 1:02 AM UTC

Along these lines, Go eliminates many formatting decisions at the syntax level. E.g.,

  func main()
  {
          fmt.Println("HELLOWORLD")
  }

is not just non-standard formatting, but illegal Go syntax. Similarly, extra parentheses around if clauses are not allowed.

Re: Formatting code should be unnecessary

#24

Post by bertil » Mon, Sep 08, 2025, 1:08 AM UTC

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

Re: Formatting code should be unnecessary

#25

Post by davetron5000 » Mon, Sep 08, 2025, 1:08 AM UTC

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...

Re: Formatting code should be unnecessary

#26

Post by yeasku » Mon, Sep 08, 2025, 1:12 AM UTC

Kind of a stupid take if you ever plan on sharing your code or using git.

Re: Formatting code should be unnecessary

#27

Post by lxe » Mon, Sep 08, 2025, 1:17 AM UTC

> you could view the source however you wanted. Spaces vs. tabs didn't matter because neither affects the semantics and the editor on the system let you modify the program tree directly (known today as projectional editing).

But formatting still doesn't matter. Outside of whitespace-dependent languages, formatting is a subjective thing -- it's a people concern, not a computer concern. I can store my JavaScript as AST if I want to.

Re: Formatting code should be unnecessary

#28

Post by jauntywundrkind » Mon, Sep 08, 2025, 1:23 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...

I'm pretty unconvinced by the examples.

> Some of us even align other parts of our code, such repeated inline comments

> Now, the arguments block forms a table of three columns. The modifiers make up the first column, the data types are aligned in the second column, and the names are in the third column

These feel like pretty trivial routines that can be encompassed by code formatting.

We can contrive more extreme examples, like the for loop, but super custom formatting ("typesetting") like that has always made me feel awkward, feels like it givesicemse for people to use all manners of arbitrary formatting. The author has some intent, but when you run into an inconsistent code based with lots of things going on, the variance doesn't feel informative or helpful: it sucks and it's a drain.

What's stored is perhaps more minimal, some kind of reference encoding, maybe prettier-ifies for js. The meat of this article to me is that it shouldn't matter: the IDE should let you view and edit as you like:

> Everyone had their own pretty-printing settings for viewing it however they wanted.

Re: Formatting code should be unnecessary

#29

Post by PaulKeeble » Mon, Sep 08, 2025, 1:24 AM UTC

In theory we could have an IDE apply a reformatting to any piece of code we looked at and formatted any changes back to the standard for the code base on updates. One of the things I dislike is that sometimes autoformatting does a poor job and looses some information that manually formatting provides but honestly in go fmt is mostly fine it just works.

All of this seems doable, I just think for the most part we don't care very much about our preferences, it has very little impact on readability. Its definitely doable however we could view the code however we most wanted it and have it stored in a different formatting. Might not be 100% round trip stable but it probably doesn't matter.

There is always better where the defaults can be overridden and formatting forced and we only format new and changed lines to reduce potential instability but again go fmt doesn't really suffer from this so its possible to make things pretty reliable. Its simple really, there is a default formatting and the code is stored that way and we can then have our view of choice reformat the code as we want it, when its stored its stored in the default.

Re: Formatting code should be unnecessary

#30

Post by bee_rider » Mon, Sep 08, 2025, 1:30 AM UTC

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…

Is it possible converted from the DIANA ir back to something that looks like source code? Then the result of the conversion backward could be grepped, etc…