Typography in Code: A Field Guide to Whitespace, Part 1

We all know what we like and what we don’t like when it comes to whitespace in programming. I can only speak for myself, but here are some elements to consider.

One of the universally accepted natures of code is to indent where appropriate, and this first installment of Typography in Code: A Field Guide to Whitespace will focus on the various incarnations of the all-important topic of (queue thundering god voice) indentation.

Topic: Tabs versus Spaces

This primordial, often invisible question is at the heart of the indentation beast. Like good and evil, right and wrong, vim and emacs — tabs and spaces are diametric opposites, warring factions facing one another across a never-ending epoch in which all our text files are smoking battlefields. One kicker is that both sides use ninja assassins. YOU CANNOT SEE THEM COMING, until… that is… you find them lurking in your legacy code, buried at the beginnings of lines near the ends of your files, like trip mines in long forgotten functions.

This is when you spend hours constructing that one perfect regex to rid your code of the enemy once and for all. (Also, unless, of course, you are one of those odd ducks who likes to see their whitespace characters. I respect you, even if you are crazy.)

Where I fall on this fence: My heart titters for tabs. But I didn’t always believe in them! I admit it, I was once an indentation swing state. But here’s why tabs are king for indenting: Tabs are like using semantic markup. We all (mostly) want code to all indent the same width (no matter what that width is), and a single tab character means that width. You can even change this width (tab stop) with a single command in any decent editor. This alone should be enough for the triumph of tabs over spaces.

Topic: How wide?

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. (Linus Torvalds, From Documentation/CodingStyle of Linux, via wikipedia)

This is a trickier beast. I believe in the power of four. It’s more legible (discernible) than two, especially across dozens of lines, and eight is just too wide a gap. With a tabstop of eight, you only get ten indentations before you’re out of 80 column width entirely! This is as opinionated as I get, since four just looks right to me, and I can’t really cite any good reasons for it. Just take it from me: you’re an IDIOT if you prefer anything else.

Yea, and the number of spaces to equal one tab shall be four. No less, and no more. The number shall not be three, and the number shall not be five. Fuck that the number shall definitely not be odd. The number shall not be two, and the number shall not be eight. The number shall be four.

Truthfully, I don’t care what your tabstop is set to, as long as these things are true:

1. I can set my tabstop to something different and the code doesn’t look all fucked up. This means, yes, tabs.
2. Never use a combination of tabs and spaces. (Fuck you, default dreamweaver settings.)
3. Tabs should never be used anywhere but at the beginnings of lines. (This violates #1, but is also a really bad practice for other reasons that maybe I’ll get into in a later article.)
4. Consistency, consistency, consistency. (WTF BSD, WTF!?)

Extra Credit: Read (and care about) the wikipedia article on Indent Style.

Next topic: How many line breaks look the best: Between Function Definitions, In Functions, Around Comments, and more!