Indent style
|
|
In computer programming, an indent style is a convention governing the indentation of blocks of code to convey the program's structure. This article largely addresses the C programming language and its descendants, but can be (and frequently is) applied to any programming language (especially those in the curly brace family). Indent style is just one aspect of programming style.
Indentation is not a requirement of most programming languages. Rather, programmers indent to better convey the structure of their program. In particular, indentation is used to show the relationship between control flow constructs such as conditions or loops and code contained within and outside them. However, some programming languages (such as Python and Occam) use the indentation to determine the structure instead of using braces or keywords.
The size of the indent is somewhat independent of the style. Many early programs used tab characters for indentation, for simplicity and to save on source file size. Unix editors generally view tabs as equivalent to eight characters, while Macintosh environments would set them to four, creating confusion when code was transferred back and forth. Modern programming editors are now often able to set arbitrary indentation sizes, and will insert the appropriate combination of spaces and tabs. They can also help with the cross-platform tab confusion by being configured to insert only spaces.
There are a number of computer programs that automatically correct indent styles as well as the length of tabs. A famous one among them is indent, a program included with many Unix-like operating systems. These programs work best for those who use an indent style close to that considered "proper" by their programmers; those who use other styles will more likely become frustrated.
| Contents |
BSD/Allman style
The BSD/Allman style is relatively common. It puts the brace associated with a control statement on the next line, indented to the same level as the control statement. Statements within the braces are indented to the next level.
while(x == y)
{
something();
somethingelse();
}
finalthing();
Proponents of this style believe that the indented code is clearly set apart from the containing statement by lines that are almost completely whitespace; the braces line up with the statement they conceptually belong to; and the ending brace lines up with the beginning brace.
One disadvantage of this style is that each of the enclosing braces occupies an entire line without adding any visible instructions. This once was a very important consideration when programs were usually edited on terminals that displayed only 24 lines, but is less significant now.
K&R style
The K&R style, so-called because it was used in Kernighan and Ritchie's book The C Programming Language, is less common. It keeps the first opening brace on the same line as control statement, indents the statements within the braces, and puts the closing brace on the same indentation level as the control statement (on a line of its own).
while (x == y) {
something();
somethingelse();
}
finalthing();
People who prefer this style often refer to it as the "One True Brace Style" (abbreviation 1TBS). The source code of the UNIX kernel and Linux kernel is written in this style.
Proponents believe advantages of this style are that the ending brace lines up with the statement it conceptually belongs to; and the beginning brace does not occupy an entire line by itself.
One disadvantage of this style is that the beginning brace can be more difficult to locate than with the BSD style, and the ending brace shares the disadvantage of the BSD style. The latter can be partially resolved in if/else blocks and do/while blocks:
if (x < 0) {
printf("Negative");
negative(x);
} else {
printf("Positive");
positive(x);
}
However, this also somewhat decreases the readability of the code.
Whitesmiths style
The Whitesmiths style is relatively common. It puts the brace associated with a control statement on the next line, indented. Statements within the braces are indented to the same level as the braces.
while (x == y)
{
something();
somethingelse();
}
finalthing();
The perceived advantages of this style are similar to those of the BSD style. Advocates of this style believe that the braces combine a series of declarations and statements into a single statement. Therefore, they should be indented as subordinate to the control statement instead of lined up with it.
Proponents of the BSD style argue that the Whitesmiths style has the disadvantage that the braces do not stand out as well. This is largely a matter of opinion; it could be argued that the brace stands out equally well being the last thing more indented as the first thing indented to the previous level.
Another disadvantage of this style is that while it works well with statements, it does not work as well with some other language structures. For example, class visibility identifiers in C++ can be difficult to spot. There are ways to mitigate this somewhat, such as using a blank line before scope identifiers (and nowhere else), but this is not a part of indent style.
class Foo class Foo
{ {
private: private:
void func1(); void func1();
void func2(); void func2();
public:
void func3(); public:
void func4(); void func3();
}; void func4();
};
GNU style
The GNU style is a mixture of the BSD and Whitesmith styles. Instead of putting the braces with the control statement or the statements within the braces, the braces are put at the halfway point between the two indent levels. Although not directly related to indentation, GNU coding style also includes the addition of making a space between the bracketed list of arguments to a function or a construct.
while (x == y)
{
something ();
somethingelse ();
}
finalthing ();
This style maintains the advantages of BSD while satisfying many of those who prefer Whitesmiths. The layout may be influenced by Richard Stallman's background of writing in Lisp. This style is the default behavior of GNU Emacs and is mandated by nearly all maintainers of GNU project software. It is rarely used outside of the free software community.
Pico style
The style used most commonly in the Pico programming language by its designers, is different from the aforementioned styles. The lack of return statements and the fact that semicolons are used in Pico as statement separators, instead of terminators, leads to the following syntax:
stuff(n):
{ x: 3 * n;
y: doStuff(x);
y + x }