There was an interesting discussion on HackerNews last week about the Linux Kernel coding style.

During the discussion, I kicked off a minor holy war about whether one should vertically align code. I’m all for it! Let me explain why.

What Is Vertical Alignment?

Take this trivial example:

int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56;

I find easier to read as:

int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56;

At a glance I can see that “bob_age” is unusual. I can easily see that everything there is an integer without having to slide my eyes around.

This view is not universally shared – so I shall attempt to explain why many people think it is a useful style guide.

Comprehension

90% of programming is problem solving. The other 90% is understanding how the problem was solved.

Reading code isn’t much different from reading prose. We expect authors to explain their arguments clearly, not be overly verbose in their extraneous use of their chosen language, and 2 respect da common grmmatcal style.

Indeed, the Kernel coding style emphasises this heavily. How you choose a variable name is as important as what the code does.

Consider the following line of code:

var thinG=doIt(thestuff,MORE_sTuff); /* LOL! */

Even if you deeply understood the codebase, that’s not a particularly readable line of code.

var totalBill = apply_tax(initialBill, taxRate);

With a sensible application of naming conventions, spacing, and capitalisation, we’ve made the code much easier to read. That means the poor sap who inherits our code will spend less time deciphering it and more time understanding it.

Why Use Monospace Fonts?

As with all good old-fashioned flamewars, there are two equally passionate sides on the monospace vs proportional font debate.

Some heretical scum will tell you that proportional fonts are the best – ignore these heathens.

Others will sow your mind with discord as they argue for the eugenic purity of proportional fonts – those poor condemned souls.

Ultimately, it comes down to readability. What do you find easiest to aid your comprehension of the code? It’s why IDEs have colour schemes – so you can tell at a glance whether “foo” is a function, a constant, a variable, or a comment. Anything which makes it quicker for you to comprehend what a block of code does is a good thing!

This is one of the reasons spreadsheets are so popular. Columns aid readability. You can quickly scan your eyes down a column and notice if a row is significantly different to its siblings.

We Don’t Have The Tools

Interestingly, the big criticism I faced in the HN discussion was not about whether vertical alignment is useful – but around how poor our tools are.

This ruins the readability and usability of your diffs. Say you need to quickly track down a major bug due to a change in a single constant. With horizontal alignment, the diff might contain any number of changed lines, obscuring the crucial change. There are workarounds that ignore whitespace and word-based diffs, but it’s just not worth the trouble IMHO.

Andreas van Cranenburgh

…And…

If you have, say, 50 lines of assignment and you align all the values to the largest one, adding one forces you to update 50 lines. I’ve been faced with those very situations and that is when I understood how important it is not to align values like that.

scrollaway

Those arguments are valid – in certain contexts – but point to the need for better tooling.

I’m reminded of the idea of Elastic Tabstops – a method to auto align code blocks:



Our tools can easily accommodate this way of working. Computers are there to do boring and repetitive jobs for us – and CPU cycles are cheap enough to “waste” on making our code more readable.

There are plenty of examples in the Linux Kernel where vertical alignment is used to make code easier for humans to parse.

Vertical alignment doesn’t work in every context – but for quickly assessing data, its readability is unparalleled.

Coding is a creative medium through which we express our ideas. If our tools make understanding those ideas more difficult, it’s the tools which need to change – not us.