HN Reader

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.

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

There was a movement towards working with syntax trees directly and treating source code as a generated serialization of those syntax trees about 20-25 years ago. This probably started with refactoring as it was pioneered in the nineties. Things like Visual Age actually stored code in a database instead of on the file system. Later intentional programming (Charles Simonyi was pushing that) tried to also do things with this. And of course model driven development was a thing around the same time.

Refactorings (when done right) are syntax tree transformations that preserve things like referential integrity, etc. that ensure code does the same thing before and after applying a refactoring.

A rename becomes trivial if you are simply working on the symbol directly. For that to work with file based source trees, you need to parse the whole thing, keep track of where symbols are referred in files, rename the symbol and then update all the places in the source tree. That stuff becomes a lot easier when the code representation isn't a bunch of files but the syntax tree. The symbol just gets a different name. Anything that uses the symbol will still use the same symbol.

People like editing files of course and that has resulted in a lot of friction developing richer tools that don't store text but something that preserves more structure. The fact that we're still going on about formatting issues a quarter century later maybe shows that this is something to revisit. For many languages and editors, robust symbol renames are still somewhat science fiction. And that's just the most basic refactoring.

Some (sometimes) desirable source code formatting cannot be deduced from the abstract syntax tree alone:

Consider the following (pseudo-)code example:

  bar.glob = 1;
  bar.plu.a1 = 21;
  bar.plu.coza = fol;

Should this code formatted this way? Or should it be formatted

  bar.glob     = 1;
  bar.plu.a1   = 21;
  bar.plu.coza = fol;

to emphasize that three assignments are done?

Or should this code be formatted

  bar.glob      = 1;
  bar.plu .a1   = 21;
  bar.plu .coza = fol;

to bring make the "depth" of the structure variables more tabular so that you can immediately see by the tabular shape which "depth" a member variable has?

We can go even further like

  bar.glob     =   1;
  bar.plu.a1   =  21;
  bar.plu.coza = fol;

which emphasizes that the author considers it to be very important that the reader can easily grasp the magnitudes of the numbers involved (which is why in Excel or LibreOffice Calc, numbers are right-aligned by default). Or combining this with making the depth "tabular":

  bar.glob      =   1;
  bar.plu .a1   =  21;
  bar.plu .coza = fol;

Each of these formattings emphasizes different aspects of the code that the author wants to emphasize. This information cannot be deduced from some abstract syntax tree alone. Rather, this needs additional information by the programmer in which sense the structure behind the code intended by the programmer is to be "interpreted".

I have to disagree with the premise. Formatting code is a critical communication channel. Well-formatted code should tell you:

1. The developer has enough experience to understand that formatting matters.

2. The developer has enough discipline to stick with their chosen formatting rules.

3. The developer has the taste necessary to choose good formatting rules.

4. The developer has the judgement necessary to identify when other concerns justify one-off violations of the rules.

These are really important attributes for a developer to have. They affect every aspect of the code, not just formatting. Formatting is just a very quick proxy to measure those by.

Unfortunately, things like autoformatting and linter rules are destroying the signal. Goodheart's law strikes again.

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 their editor of choice, would those who prefer tabs have any other arguments?

You can't easily search / grep etc. an IR, unless you use some kind of reverse translator. Readable source files have their benefits in being simple in that sense.

This is how Chrome Dev Tools shows source code. The original is often minified or in whatever format the author left it. And when you check the "pretty" checkbox in dev tools, it shows up using whichever format Chrome developers decided it should look like.

Ah, eslint-config-airbnb. My favorite airbnb config issues:

https://github.com/airbnb/javascript/issues/1271

https://github.com/airbnb/javascript/issues/1122

I literally spent over an hour when adapting an existing project to use the airbnb config, when code was perfectly correct, clear and maintainable. I ended up disabling those specific rules locally. I never used it in another project. (Looks like the whole project is no longer maintained. Good riddance.)

The airbnb config is, in my view, the perfect example of unnecessarily wasting people's productivity when linting is done badly.

Interesting read. I’ve often wondered why the projection we see needs to be the same as the stored artifact. Even something like a git diff should be viewable via a projection of the source IR.

With things like treesitter and the like, I sometimes daydream about what an efficient and effective HCI for an AST or IR would look like.

Things like f#s ordered compilation often make code reviews more simple for me, but that’s because a piece of the intermediate form (dependency order) is exposed to me as a first class item. I find it much more simple to reason about compared to small changes in code with more lax ordering requirements, where I often find myself jumping up and down and back and forth in a diff and all the related interfaces and abstract classes and implementations to understand what effect the delta is having on the program as a whole.

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.

I like that. We should have something like this for python.

Black is great, but maybe it's just me since it aligns with how I like the code formatted.

Would there be any downsides for python (or git ?) to define a standard way of formatting to save a valid file, and all the formatting necessary to read a file happens in the IDE showing the file ?

That would very much fit with python ethos 'There should be one-- and preferably only one --obvious way to do it.'

I wouldn’t have an issue if title had „could” instead of should.

There are most likely good reasons why Ada and DIANA are not in widespread use.

Aren't most projects these days written in a mix of languages, most of them text? You'd have to get them to change to use the same tools we currently use, or else you'd have to use special tools. The beauty of the modern stack is the base tools are near universal.

If you want everyone to see their own preference of format, either write a script or get AI to format it for you.

> It's 2025, how are we still dealing with this sort of thing?

You have to get everyone set up to use it, whereas everyone is already, of necessity, set up to use plain text.

And we aren't all using the same programming language and the same hardware setup.

Thus, specifically:

* everyone has to agree on an IR standard; if it can't accommodate every programming language, then there needs to be coverage for all the programming languages, and a way for software systems to know which one to use

* everyone has to have local software that can convert back and forth (they can't just rely on something built in to the "development system", I assume burned into a ROM)

* everyone's version control setup has to invoke that software as a commit hook

* the IR has to be designed in a way that allows for meaningful diffs, and the version-control software needs to be aware of how to diff and patch (which potentially also means a new standard for diff files)

Formatting code is a typical bikeshed argument. Nobody can say a thing about the nuclear reactor, everyone has an opinion about the bike-shed.

Others have already mentioned how why this is a bad idea (e.g. common plaintext tools don't work, added complexity, etc.)

But I'll also mention that this pretty much already exists. You can have whitespace options for git. I also imagine there's some setup using hooks that uses one formatter locally, and another for remote.

Also, the common IR already exists - it's just the AST. It was "solved" back in the day when people were throwing whatever they could to the wall to see what sticks since it was all so new. With the benfit of hindsight, I think we can say that it's not that good of an idea.

> Back when he was working on Ada, they didn't store text sources at all — they used an IR called DIANA. Everyone had their own pretty-printing settings for viewing it however they wanted.

What about comments? Were they part of the IR?

(I agree with others that version control, grep etc. are also very important, and kind of a deal breaker).

With git you could set up “smudge” filters to do your own formatting on checkout and “clean” formatting for the canonical formatting on staging files.

https://git-scm.com/book/pt-br/v2/Customizing-Git-Git-Attrib...

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.

Projectional Editing can be done with text sources.

Here’s an old video of JetBrains MPS rendering a table from code https://www.youtube.com/watch?v=XolJx4GfMmg&t=63s

I’m hoping for an IDE able to render dictionaries as tables -- my wishlist doesn’t stop there.

Currently, we have a glimpse of those features, such as code folding, inlay hints, or docstrings rendered as HTML:

https://x.com/efortis/status/1922427544470438381

I think the problem can be defined equally as: we can't invest in something more abstract than "plain text" at this time. When we try, it gets downgraded to a plain text projection of the syntax.

The plain text encoding itself exists in a process of incremental, path-dependent development from Morse Code signals to Unicode resulting in a "Gigantic Lookup Table" (GLUT, my coining) approach to symbolic comprehension. The assumption is useful - lots of features can "just work" by knowing that a particular bit pattern is always a particular symbol.

If we push up the abstraction level, we get a different set of symbols that are better suited to the app, but not equivalent GLUT tooling. Instead we usually get parsing of plain text as a transport. For example, CSV parsing. It is sloppy; it is also good enough.

Edit: XML is also a key example. It goes out of its way to respect the text transport approach. There are dedicated XML editors. But people want to edit it as plain text and they can't quite get there because funny-business with character encodings gets in the way, adding a bunch of ampersands and semicolons onto the symbols they want to edit. Thus we have ended up with "the CSV of hypertext documents", Markdown.

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.

I wrote an article saturday on visual programming which is very related to this, but my thinking is the opposite of this article.

Raw text is amazing at smaller scales. The ability to apply a bunch of intermediate incorrect transformations to reach a valid destination is invaluable (like doing a bunch of hacky find/replace).

Projectional editors like JetBrains MPS have tons of disadvantages vs text, and the few advantages don't make up for it.

Formatting is a silly problem to have, but far beyond that why are we manipulating text files directly rather than editing a live program (ala Smalltalk). Text can just be the on-disk serialization format you never look at.

(Raw text is still how you edit individual functions and methods in Smalltalk, there just isn't any actual text file on disk)

The main selling point for source code in plain text files is compatibility. You can use whatever tool you wish. Yes, it's not ideal, and yes, we are still using non-semantic diffs in these days, even though it should have been a solved problem by now. I'd still argue that even if all the editing/VCS tools start working in a structured way, the storage format should be plain text.

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.

Lua is especially annoying - even after years of using it I just can't really decide how to format it for better readability. lua-fmt sometimes works, often it makes it even worse. I welcomed Fennel in my Lua setups mainly because of this.

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.

Author advocates for a thing they never used.

"It must have been good because Grady Booch says so".

One thing I absolutely despise is 2 space indentation. Instead of not creating stupid 5+ level deep nesting, people decided to decrease the indentation size. Then everyone uses tab colorizers or those stupid vertical margins in vscode, because you can't read it otherwise. And then those people put it everywhere with some opinionated formatters - looking at you Elixir. I don't even have vision problems and it's already shit to look at.

Ohhh, a topic about code formatting

<picks pop-corns>

I am quite thankful for Go. It ticks so many boxes. Having native gofmt and simple syntax means I can easily read anyone else's code instantly.

In most languages (other than e.g. Python), formatting code is actually unnecessary...

Typing keywords letter by letter is unnecessary too. Think about ZX Spectrum keyboard allowing you to type BASIC keywords with just one key press.

I came prepared to fight the author, but I left in agreement.

Yes, we should expect better from our tools and languages.

This article is barely a comment on some other situation; but I've been saying this to anyone who wants listen for years.

There's nothing special about whitespace (unless you write python).

Capitalization and a bunch of other stuff in your coding convention document are usually just signs that you have poor tooling and lack of skill.

Give me a PR that satisfies the requirements and the appropriate test cases and i'll happily rewrite it to spaces only indented with curly braces on newlines and etc... as I see fit.

The hard part is the first two tasks, you can train an intern to do the third

tbqh I would be insanely happy if a formatter would format code the team's way when committing/pushing and my way when I'm viewing locally

I've never found a single formatter that formats my way though...

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

A small point on formatting that I'm getting increasingly firm about as I "age" (still not that old): Formatting is very important, but if you find yourself complaining about what a formatter does to your code, the code be bad (obviously making an exception for a big block of constants or something)

e.g. if the formatter is really shifting stuff around, your code might be too nested - if you have a compiler, let it take the strain.

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

This is how darklang works as well.

Whitespace being important is literally the reason I don't use Python. I'm absolutely TERRIBLE with whitespace in my code, I do not indent like most people, I indent a lot less frequently. I learned coding on TRS80 Model 100 basic, and in DOS with Borland IDEs. Bytes mattered! :D

Code layout is important, even though it - much like naming - doesn't impact functionality.

I can write code that (IMHO) is substantially better than any formatter. But I've realized that there is no way to make other people on a team have the same opinions and skill as me, so I accept automatic code formatters.

So I need to run a tool to even be able to read the code. No thank you, if anything goes wrong your file is now garbage.

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

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

I think that formatting code is necessary to maintain a codebase that's used by multiple people and keep some consistency. It's very confusing to have different standards in different parts of the same code.

Code should be generally written so it's easy to read.

my initial gut take from the title was "OH MY GOODNESS don't let {x} toxic developer who writes TERRIBLE code see this as justification". There are enough toxic bros who either 1. think this is unnecessary or 2. think it is perfectly solved.

re: intermediate representation and projectional editing: yes, editors are now getting better at helping you refactor code (rename function in language XYZ is possible in language servers for IDEs, /no AI required, it works better when a human coded AST tool does it/)

projectional editors aren't around /because the more complex parts of it are harder/ - BUT - I could definitely see more intelligent refactor tooltips written by humans.

For example: in Rust, if I've been passing a pointer vs borrowing (or whatever), pattern A for most of my code, then pattern B and it complains, it would be useful to have a tooltip that goes "do you want to refactor all the other references/parameters to pattern B" instead of Rust's default "this function isn't using pattern A" borrow checker error.

some people do not understand the difference between form and substance

In Javascript there is Prettier which auto-formats the code on saving: https://prettier.io/ So essentially you stop caring about adding new lines or tabs, just press save and the code gets indented/formatted correctly.

line length limits make code harder to grep

Io (http://iolanguage.org) can work this way, as the message tree (maybe including comments - I don't recall) is what the interpreter used to evaluate the code and is accessible at runtime. However, it didn't store the choice of terminator (newline vs return) or indentation info (though it would be easy to add), so the pretty print of the message tree might look different depending on the source conventions.

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 have heard that this was one of the goals of developing IDLs. I think the vision was, that you could have a dozen different programmers, working in multiple languages (for example, C for the drivers, Haskell for the engine, and Lua for the UI). They would be converted to a common IDL, when submitted to configuration management, and then extracted from that, when the user looks at it.

I can't see that working, but a lot of stuff that I used to think was crazy, has happened, so, who knows?

I feel like squeezing out every possible place for people to be creative and express themselves creates a pretty boring environment. Like, imagine if all buildings were just purely functional. They'd all be the same grey box shaped things. I recently worked on a codebase that was lovingly developed by a single maintainer and had all kinds of weird and wonderful quirks that made me smile every so often. I'm a pretty serious person most of the time but I'm not going to lie it made my day that little bit more interesting.

Storing an IR also means we can create languages beyond the limits of syntactical practicality. Imagine, for example, an entire comment/documentation dimension of the code. Instead of commenting on a line near some code, you could attach comments semantically to an expression, or to a variable, or to any unit of code.

It never ceases to amaze me how many times people can essentially re-invent S-expressions without realizing that's what they are doing.

There are multiple ways to write exactly the same program. Linters are able to reduce this number by moving to some canonical version.

With modern tools it it is easy to add formatting on saving or on commit. So I don't understand what's the fuss about.

At the same time, for the most important tool in software engineering, Git, it matters which lines are changes. And it is better to only see actual logic changes, not swamped in tabs vs space or other parts that are just formatting.

That said, I would love to see more of this splitting between actual internal representation and view. Don't like anything in style guide (or even syntax alike curly brackets vs indentions) - just change view, alike folding.

It basically is, unless you’re in a whitespace-Nazi language like Python (no offense!).

It doesn’t get much less formatted than Minified JavaScript, except maybe Perl or Brainfuck.

Ahh yes, nothing brings out the strong opinions like formatting. Let's do SQL next!

I assume that's something similar to the Unison [1] programming language

https://www.unison-lang.org/

you don't say

With how much LLMs do nowadays, I'm waiting for the time when specifying types is unnecessary. Like, it if can write code, shouldn't we also be able to have an AI type checker?

Formatting code is unnecessary. You write it however you want, then run the lint fix command and prettier command, commit, and move on.

good luck with that.. I didn't had a decent IDE capable of even implementing elastic tab stops... I expect people using hex editors to flip bytes directly on the binary blob saved on disk instead of using the appropriate tools to view the "source" files.

btw: have a look at how much disdain was reserved for systemd and its pletora of binary blobs + custom tools (e.g. the journal stuff) ... and that was basically forced upon from the distributions

I wish for Java to have a built-in formatter just like Go has. Enough with these plugins and google-format and messy intelij settings.