Programming style

Programming style refers to a set of rules or guidelines used when writing the source code for a computer program. It is often claimed that following a particular programming style will help programmers quickly read and understand source code conforming to the style as well as helping to avoid introducing faults.

A classic work on the subject was The Elements of Programming Style, written in the 1970s, and illustrated largely with examples from the Fortran language prevalent at the time.

The programming style used in a particular program may be derived from the coding standards or code conventions of a company or other computing organization, as well as the preferences of the author of the code. Programming styles are often designed for a specific programming language (or language family), but some rules are commonly applied to many languages. (Style considered good in C source code may not be appropriate for BASIC source code, and so on.)

Elements of good style

Good style, being a subjective matter, is difficult to concretely categorize; however, there are several elements common to a large number of programming styles. The issues usually considered as part of programming style include the layout of the source code, including indentation; the use of white space around operators and keywords; the capitalization or otherwise of keywords and variable names; the style and spelling of user-defined identifiers, such as function, procedure and variable names; the use and style of comments; and the use or avoidance of programming constructs themselves (such as GOTO statements).

Code appearance

Programming styles commonly deal with the appearance of source code, with the goal of improving the readability of the program. However, with the advent of software that formats source code automatically, the focus on appearance will likely yield to a greater focus on naming, logic, and higher techniques. As a practical point, using a computer to format source code saves time, and it is possible to then enforce company-wide standards without debates.

Indenting

Indent styles assist in identifying control flow and blocks of code. In programming languages that use indentation to delimit logical blocks of code, indentation style directly affects the behaviour of the resulting program. In other languages, such as those that use brackets to delimit code blocks, the indentation style does not directly affect the product. Instead, using a logical and consistent indentation style makes code more readable. Compare:

if (hours < 24 && minutes < 60 && seconds < 60)
{
    return true;
}
else
{
    return false;
}

or

if (hours < 24 && minutes < 60 && seconds < 60) {
    return true;
} else {
    return false;
}

with something like

if  (    hours<
24  && minutes<
60  && seconds<
60  )
{return    true
;}         else
{return   false
;}

The first two examples are probably much easier to read because they are indented in an established way (a "hanging paragraph" style). This indentation style is especially useful when dealing with multiple nested constructs.

This example is somewhat contrived, of course; all the above are equivalent to the more concise statement

return (hours < 24) && (minutes < 60) && (seconds < 60);

Python uses indentation to indicate control structures, so correct indentation is required. By doing this, the need for bracketing with curly braces ({ and }) is eliminated, and readability is improved while not interfering with common coding styles. This can lead to problems where code is copied and pasted into a Python program, because the indentation level of the pasted code may not be the same as the indentation level of the line in the code into which it is being pasted. Such reformatting is tedious to do by hand, but some text editors and IDEs have features to do it automatically. Additionally, Python code can be rendered unusable when posted on a forum or webpage that removes whitespace: on webpages, Python code should be enclosed in "<pre> ... </pre>" HTML tags to be properly displayed.

Haskell similarly has the off-side rule which lets indentation define blocks; however, unlike in Python, indentation is not compulsory in Haskell — curly braces and semicolons can be (and occasionally are) used instead.

Vertical alignment

It is often helpful to align similar elements vertically, to make typo-generated bugs more obvious. Compare:

$search = array('a', 'b', 'c', 'd', 'e');
$replacement = array('foo', 'bar', 'baz', 'quux');

with:

$search      = array('a',   'b',   'c',   'd',   'e');
$replacement = array('foo', 'bar', 'baz', 'quux');

The latter example makes two things intuitively clear that were not clear in the former:

the search and replace terms are related and match up: they are not discrete variables;
there is one more search term than there are replacement terms. If this is a bug, it is now more likely to be spotted.

Arguments against vertical alignment generally claim difficulty in maintaining the alignment.

Spacing

The grammars of most free-format languages are mostly unconcerned with the presence or absence of whitespace. Making good use of spacing in code layout is therefore considered good programming style.

Compare the following syntactically equivalent examples of C code.

 int i;
 for(i=0;i<10;++i){
     printf("%d",i*i+i);
 }

versus

 int i;
 for (i = 0; i < 10; ++i) {
     printf("%d", i*i + i);
 }

It is also recommended to avoid using tab characters in the middle of a line as different text editors render their width differently.

Naming, logic, and higher techniques

Appropriate variable names

Appropriate choices for variable names are seen as the keystone for good style. Poorly-named variables make code harder to read and understand.

For example, consider the following pseudocode snippet:

get a b c 
if a < 24 and b < 60 and c < 60
  return true
else
  return false

Because of the choice of variable names, the function of the code is difficult to work out. However, if the variable names are made more descriptive:

get hours minutes seconds 
if hours < 24 and minutes < 60 and seconds < 60
  return true
else
  return false

the code's intent is easier to discern, namely, "Given a 24-hour time, true will be returned if it is a valid time and false otherwise".

Boolean values in decision structures

Some programmers think decision structures such as the above, where the result of the decision is merely computation of a Boolean value, are overly verbose and even prone to error. They prefer to have the decision in the computation itself, like this:

return (hours < 12) && (minutes < 60) && (seconds < 60);

The difference is often purely stylistic and syntactic, as modern compilers produce identical object code for both forms.

However, one argument in favour of the former is that some debuggers allow you to step line by line: if your test also caused changes to the variables you were testing, and you wanted to examine the values of all variables after that test, then only the former method would permit that to be debugged. The latter would not allow your debugger to reach a line "after the test" where those variables still existed.

Left-hand comparisons

In languages which use a single = for assignment and a double == for comparison, and where assignments may be made within control structures, it is sometimes considered good programming style to place constants to the left in any comparison.[1] The following lines are functionally identical:

if ( true == $a ) { ... }
if ( $a == true ) { ... }

However, of the two following, typoed lines, the first is a syntax error that will be diagnosed by the interpreter, while the latter is a subtle bug that sets the value of $a to be true, then evaluates to true.

if ( true = $a ) { ... }
if ( $a = true ) { ... }

Looping and control structures

The use of logical control structures for looping adds to good programming style as well. It helps someone reading code to understand the program's sequence of execution (in imperative programming languages). For example, in pseudocode:

i = 0
while i < 5
  print i * 2
  i = i + 1
end while

The above snippet obeys the naming and indentation style guidelines, but the following use of the "for" construct makes the code much easier to read:

for i = 0, i < 5, i=i+1
  print i * 2

In many languages, the often used "for each element in a range" pattern can be shortened to:

for i = 0 to 5
  print i * 2
print "Ended loop"

In curly bracket programming languages, it has become common for style documents to require that even where optional, curly brackets be placed after all control flow constructs.

for (i = 0 to 5) {
  print i * 2;
}
print "Ended loop";

This prevents program-flow bugs which can be time-consuming to track down, such as where a terminating semicolon is introduced at the end of the construct (a common typo):

 for (i = 0; i < 5; ++i);
    printf("%d\n", i*2);    /* The incorrect indentation hides the fact that this line is not part of the loop body. */
 printf("Ended loop");

...or where another line is added before the first:

 for (i = 0; i < 5; ++i)
    fprintf(logfile, "loop reached %d\n", i);
    printf("%d\n", i*2);    /* The incorrect indentation hides the fact that this line is not part of the loop body. */
 printf("Ended loop");

Lists

Where items in a list are placed on separate lines, it is sometimes considered good practice to add the item-separator after the final item, as well as between each item, at least in those languages where doing so is supported by the syntax (e.g, C):

 const char *array[] = {
     "item1",
     "item2",
     "item3",  /* still has the comma after it */
 };

This prevents syntax errors or subtle string-concatenation bugs when the list items are re-ordered or more items are added to the end, without the programmer's noticing the "missing" separator on the line which was previously last in the list. In other languages, such as ECMAScript, however, this practice is a syntax error, so programmers should evaluate the target language before adopting this technique.

External links

Coding conventions for languages

Coding conventions for projects

Mozilla Coding Style Guide
Linux Kernel Coding Style (or Documentation/CodingStyle in the Linux Kernel source tree)
The NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)