Programming style

Elements of good style

Good style is a subjective matter, and is difficult to define. 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; and the use and style of comments.

Code appearance

Programming styles commonly deal with the visual appearance of source code, with the goal of readability. Software has long been available that formats source code automatically, leaving coders to concentrate 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.

Indentation

Indent styles assist in identifying control flow and blocks of code. In some programming languages indentation is used to delimit logical blocks of code; correct indentation in these cases is more than a matter of style. In other languages indentation and white space do not affect function, although logical and consistent indentation makes code more readable. Compare:

or

with something like

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.

Note however that this example is the same as simply:

ModuLiq

The ModuLiq Zero Indent Style groups with carriage returns rather than indents. Compare all of the above to:

Lua

Lua does not use the traditional curly braces or parenthesis. if/else statements only require the expression be followed by then, and closing the if/else statement with end.

Indentation is optional. and,or,not are used in between true/false statements.

They are true/false statements, as

would mean false.

Python

Python uses indentation to indicate control structures, so correct indentation is required. By doing this, the need for bracketing with curly braces (i.e. { and }) is eliminated. On the other hand, copying and pasting Python code can lead to problems, because the indentation level of the pasted code may not be the same as the indentation level of the current line. Such reformatting can be tedious to do by hand, but some text editors and IDEs have features to do it automatically. There are also problems when Python code being rendered unusable when posted on a forum or web page that removes white space, though this problem can be avoided where it is possible to enclose code in white space-preserving tags such as "

Notice that Python does not use curly braces, but a regular colon (e.g. else:).

Many Python programmers tend to follow a commonly agreed style guide known as PEP8. There are tools designed to automate PEP8 compliance.

Haskell

Haskell similarly has the off-side rule which lets indentation define blocks. However, unlike Python, Haskell uses whitespace in this fashion simply as a form of syntactic sugar—explicit 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:

with:

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

However, note that there are arguments against vertical alignment:

For example, if a simple refactoring operation is performed on the code above, renaming variables "$replacement" to "$r" and "$anothervalue" to "$a", the resulting code will look like this:

The original sequential formatting will still look fine after such change:

Spaces

In those situations where some white space is required, the grammars of most free-format languages are unconcerned with the amount that appears. Style related to white space is commonly used to enhance readability. There are currently no known hard facts (conclusions from studies) about which of the whitespace styles have the best readability.

For instance, compare the following syntactically equivalent examples of C code:

versus

versus

Tabs

The use of tabs to create white space presents particular issues when not enough care is taken because the location of the tabulation point can be different depending on the tools being used and even the preferences of the user.

As an example, one programmer prefers tab stops of four and has his toolset configured this way, and uses these to format his code.

Another programmer prefers tab stops of eight, and his toolset is configured this way. When he examines his code, he may well find it difficult to read.

One widely used solution to this issue may involve forbidding the use of tabs for alignment or rules on how tab stops must be set. Note that tabs work fine provided they are used consistently, restricted to logical indentation, and not used for alignment: