Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Indenting
One of the biggest holy wars in computing comes from how you indent code. Do you use tabs or spaces? If you use spaces, how many do you use?
The absolute worst thing that you can do is use both tabs and spaces. The GNU coding conventions do this and mandate that tabs are treated as 8 spaces. No editor that I use defaults to 8-wide tabs, so whenever I open a file in the GNU coding style, the indenting looks completely random until I change the tab size.
The advantage of spaces is that they look the same on everyone's computer. I'm not convinced by this argument; looking the same is not as important as being readable. Most of the arguments that I've read against using tabs come from problems with people mixing tabs and spaces, rather than problems intrinsic with tabs.
Note, however, that indenting is not the same as alignment. Indenting is something that is used to provide hints about language semantics (specifically, scope), while alignment is used to improve readability.
If you define a structure in C, then you might want to line up all of the variable names, like this:
struct foo
{
int a;
float b;
double c;
};
If you used tabs for the spaces between the variable types and names, then they will only line up if you used the same tab width as the person viewing the file. Using tabs here, therefore, will only work if you mandate a fixed tab size in your style guides.
I prefer a hybrid approach, where indenting is done with tabs—one tab per indent level—and alignment is done with spaces. In the previous example, each of the lines inside the braces starts with one tab, but the names and types are separated by spaces.
This means that you can set your tab width to whatever you want when you view the code, so that all indented lines will be the same distance from the left and all aligned values will remain aligned. This is most important in languages like Smalltalk and Objective-C, where it's common to split message sends over multiple lines and align the arguments. Consider this example:
[aDictionary setObject: a
forKey: b];
In this example, the first line is indented by one tab. The second line, because it is in the same scope, is also indented by one tab. This tab is then followed by a series of spaces so that the colons line up.
I usually have my editor configured to display tabs as red arrows, so I can see the structure of code using this style without reading a single character, just by looking at the shape of the wave of red color down the left-hand side. By using a different character for indenting and alignment, it's easy to see when some spacing is caused by indenting and when by alignment. This is especially important for things like if statements that overrun a line.
One good way of evaluating a particular set of style recommendations is the loren ipsum approach, which is used when assessing typographical layouts. These substitute some repeated Latin verse for real text, so you just see the layout. If you take a piece of code and replace all the characters with Greek letters, how much of the underlying structure can you still infer? With good coding conventions, it's a surprising amount.