Code Formatters End Arguments

Code Formatters End Arguments

Every team that has argued about tabs and spaces learns the same thing: the argument never ends. It moves into code review, where it comes back one comment at a time, on every change, for as long as the project lives.

Automatic formatting is one of the few practices in software I would call nearly free. Not because any particular style is right, but because handing the decision to a machine removes a whole category of disagreement from the room.

Cheap comments crowd out expensive ones

A reviewer has a limited amount of attention for each change. Pointing out a missing space or a brace on the wrong line takes no thought at all, so those comments arrive first and in quantity. The comment that matters, the one asking why this function swallows an error, has to compete with them. Often it never gets written, because the review already feels thorough.

The author pays as well. Twelve comments about whitespace read as criticism even when nobody meant them that way, and the conversation about the actual design starts with someone already defensive.

Having a style beats choosing the best one

Most style choices are close to arbitrary. Two spaces or four, single quotes or double, a trailing comma or not: each has its arguments, and none of them decides whether the software works. Consistency is what helps. When every file looks the same, your eye stops noticing the layout and starts noticing the logic.

That is why the formatters that stuck are the opinionated ones. gofmt gives Go programmers almost no choices. Prettier keeps its options few on purpose. Black describes itself as uncompromising. The Go community has a saying that gofmt's style is nobody's favourite, yet gofmt is everybody's favourite, which is the whole case in one sentence. Pick a widely used formatter, accept its defaults, and spend the saved time on something else.

What review looks like afterwards

Here is a small function as it might look after a few hurried edits (invented for this post), and the same function after a formatter has been over it:

// Before
function invoiceTotal(lines,taxRate){let sum=0
  for(const l of lines){if(l.qty>0){sum+=l.price*l.qty}}
    return Math.round(sum*(1+taxRate)*100)/100}

// After
function invoiceTotal(lines, taxRate) {
  let sum = 0;
  for (const l of lines) {
    if (l.qty > 0) {
      sum += l.price * l.qty;
    }
  }
  return Math.round(sum * (1 + taxRate) * 100) / 100;
}

The formatter changed nothing about what the code does. It changed what a reviewer notices. In the first version the eye goes to the mess. In the second the real questions stand out: a line with a negative quantity is silently dropped, when it might be a credit note that should reduce the total, and money is being calculated and rounded in floating point, which can leave a total off by a paisa. Those are the comments worth writing, and now there is room for them.

If it is not automatic, it will not happen

A formatter people must remember to run is a style guide with extra steps. Run it on save in the editor, and again as a check before anything merges, so unformatted code cannot get in at all. When adopting one on an existing project, reformat everything in a single commit that does nothing else, so the history keeps layout changes and logic changes apart.

For code that did not come from your team

A team formatter only covers code the team writes. The Code Formatter & Beautifier on my projects page is a small tool for everything else: a minified script you need to understand, a file inherited from somebody who has moved on, a snippet pasted with its indentation destroyed. Minified code is readable by machines and by nobody else. The tool takes it to readable in one click across several languages, and goes past whitespace: it validates the syntax and reports errors, because code that reads badly is often formed badly too. A snippet library sits alongside it for the patterns you reach for again and again.

It does have formatting options, which might seem to contradict everything above. The useful way to treat them is as a means of matching a stranger's file to the house style already in place, not as an invitation to reopen the debate. Let the machine be pedantic, so that people do not have to be.