Code Layout Styles

by Darren Collins
Monday, 8 July 2002

Most modern computer languages like C and C++ give programmers considerable scope to lay out and format their code as they see fit. This is a huge improvement over older languages that forced you to put things in particular columns, limited the length of a line of code, or used special continuation characters to split long statements over multiple lines. As with all such freedoms, though, comes room for abuse.

This article describes the most common style of code layout. All of them try to make your code easier for yourself and others to read and understand.

I won't try to get you to choose any one style over the others. The most important point is that you choose the style that works for you, and stick to it. Don't change layout styles for different routines, and especially don't mix styles within the same routine! Consistency is key.

If you're working on code that someone else has written, the best thing to do is to make your changes using the same style. Even if you hate the style, just make your changes and move forward with your life! When you rearrange the layout of working code, you run the risk of inadvertently introducing new errors. The worst thing about these types of errors is that they'll be in unfamiliar parts of the code, not the part you were really modifying, so they'll be difficult to track down and fix.

The four most common styles of code layout are:

K&R Style

This style is named after Kernighan and Ritchie, the guys that wrote the defining book "The C Programming Language" in 1978, because the examples in the book are formatted in this way. It is also sometimes known as "kernel style" or the "One True Brace Style" (1TBS), and usually uses 8-space tabs:

if (<cond>) {
<body>
}

Allman Style

This is my preferred style and is named after Eric Allman, who wrote a lot of the BSD-Unix utilities. It is also sometimes known as "BSD style". It uses either 8- or 4-space tabs in C code, but usually 4-space tabs in C++ code:

if (<cond>)
{
<body>
}

GNU Style

As the name suggests, this style is used in the GNU Emacs (an editor) and Free Software Foundation (FSF) code. It uses 4-space tabs, but the braces are halfway between tabs:

if (<cond>)
{
<body>
}

Whitesmiths Style

This is the style used in the examples shipped with the early compiler "Whitesmiths C". It usually uses 8-space tabs, but 4-space tabs are common:

if (<cond>)
{
<body>
}

Practical Considerations

In my experience, the most common styles are variations on K&R and Allman. I've never come across code written in either of the other two styles. K&R style has the advantage that it uses less lines of your screen than other styles to display the same code. With the other styles, though, the opening brace '{' is easier to see at a glance, making the start and end of the code body more obvious.

The number of spaces per tab is a subjective thing - I think that 4 is a good tradeoff between isolating related code and fitting it all on the screen. Many Unix editors default to 8-space tabs, but I find I quickly run off the right side of the screen in nested loops.

A related style rule that I've found important is to always use braces with 'if', 'while', 'for', etc statements. Both C and C++ let you write a one-line 'if' statement like this:

if (<cond>)
DoThis();

This layout can cause problems if someone later tries to add extra code before the function call:

if (<cond>)
Log("Condition is TRUE.\n");
DoThis();

The above code doesn't immediately look wrong to programmers new to C/C++, but in actual fact the DoThis() function will always execute, whether or not <cond> is true. It can make for really strange program behaviour, especially when you think you've only added a few debugging statements without changing the code's logic.

Using the form below (modify the example to reflect your favourite style!) tends to avoid this problem altogether:

if (<cond>)
{
DoThis();
}

Whichever style you choose for your own code, you can be guaranteed one thing - someone, somewhere, will call you an idiot for choosing it. Don't listen. Like religions, most people have already made up their mind and you won't change it by arguing. Just apply your own choice consistently.

 


Related Articles
Index
- Links - C/C++
- Code Layout Styles
- Const Correctness Part 1
- Const Correctness Part 2
- Const Correctness Part 3
- Const Correctness Part 4
- Const Correctness Part 5
- Const Correctness Part 6

This site Copyright 1999-2005 Darren Collins.