Programming style

Programming style, also known as coding style, is the manner in which source code is written that results in distinctive characteristics of the code; the resulting code style.

Many consider consistent style within a codebase to be valuable; to make the code easier to read and more maintainable. Often, a programmer follows style guidelines with the intent of producing code that follows a consistent style not only in their body of work but in the work of all those using the same guidelines.

Style guidelines come in many forms. They may be described in coding conventions in a standard or programmers may adhere to common practices and defacto standards. Guidelines may be descriptive such as write clearly – don't be too clever or prescriptive such as indentation is 4 spaces. Various books such as The Elements of Programming Style provide code style examples.

As with style in general, code style can be described as many separate aspects such as indentation, naming, and capitalization.

Aspects of code style are often used in the context of a specific programming language or language family. A style aspect used for C may not be appropriate for BASIC. However, some style aspects apply to many languages.

Automation

In some cases, adherence to style can be achieved via software tools. A tool that formats code allows coders to focus on other aspects such as logic and naming. Using such tools can result in a more consistent code style with less effort from the coders.

Style aspects

Aspects of code style include but are limited to:

• Indentation and other white space
• Naming of user-defined identifiers
• Capitalization of keywords (when allowed by the language)
• Use of comments

Indentation

Indentation style can assist a reader in various way including: identifying control flow and blocks of code. In some programming languages, indentation is used to delimit blocks of code and therefore is not matter of style. In languages that ignore white space, indentation can affect readability.

For example, formatted in a commonly-used style:

if(hours<24&&minutes<60&&seconds<60){returntrue;}else{returnfalse;}

Arguably, poorly formatted:

if(hours<24&&minutes<60&&seconds<60){returntrue;}else{returnfalse;}

Notable indentation styles

ModuLiq

The ModuLiq Zero Indentation Style groups by empty line rather than indentation.

Example:

if(hours<24&&minutes<60&&seconds<60)returntrue;elsereturnfalse;

Lua

Lua does not use the traditional curly braces or parentheses; rather, the expression in a conditional statement must be followed by then, and the block must be closed with end.

ifhours<24andminutes<60andseconds<60thenreturntrueelsereturnfalseend

Indentation is optional in Lua. and, or, and not function as logical operators.

Python

Python relies on indentation to indicate control structure, thus eliminating the need for bracketing (i.e. { and }). 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 "<pre> ... </pre>" (for HTML), "[code]" ... "[/code]" (for bbcode), etc.

ifhours<24andminutes<60andseconds<60:returnTrueelse:returnFalse

Notice that Python starts a block with a colon (:).

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

Haskell

Like Python, Haskell has the off-side rule. It has a two-dimension syntax where indentation is meaningful to define blocks (although, an alternate syntax uses curly braces and semicolons).

Haskell is a declarative language, there are statements, but declarations within a Haskell script.

Example:

letc_1=1c_2=2infxy=c_1*x+c_2*y

may be written in one line as:

let{c_1=1;c_2=2}infxy=c_1*x+c_2*y

Haskell encourages the use of literate programming, where extended text explains the genesis of the code. In literate Haskell scripts (named with the lhs extension), everything is a comment except blocks marked as code. The program can be written in LaTeX, in such case the code environment marks what is code. Also, each active code paragraph can be marked by preceding and ending it with an empty line, and starting each line of code with a greater than sign and a space. Here an example using LaTeX markup:

Thefunction\verb+isValidDate+testifdateisvalid\begin{code}isValidDate::Date->BoolisValidDatedate=hh>=0&&mm>=0&&ss>=0&&hh<24&&mm<60&&ss<60where(hh,mm,ss)=fromDatedate\end{code}observethatinthiscasetheoverloadedfunctionis\verb+fromDate::Date->(Int,Int,Int)+.

And an example using plain text:

ThefunctionisValidDatetestifdateisvalid>isValidDate::Date->Bool>isValidDatedate=hh>=0&&mm>=0&&ss>=0>&&hh<24&&mm<60&&ss<60>where(hh,mm,ss)=fromDatedateobservethatinthiscasetheoverloadedfunctionisfromDate::Date->(Int,Int,Int).

Vertical alignment

Some programmers consider it valuable to align similar elements vertically (as tabular, in columns), citing that it can make typo-generated bugs more obvious.

For example, unaligned:

$search=array('a','b','c','d','e');$replacement=array('foo','bar','baz','quux');$value=0;$anothervalue=1;$yetanothervalue=2;

aligned:

$search=array('a','b','c','d','e');$replacement=array('foo','bar','baz','quux');$value=0;$anothervalue=1;$yetanothervalue=2;

Unlike the unaligned code, the aligned code implies that the search and replace values are related since they have corresponding elements. As there is one more value for search than replacement, if this is a bug, it is more likely to be spotted via visual inspection.

Cited disadvantages of vertical alignment include:

• Dependencies across lines which leads to maintenance load. For example, if a long column value is added that requires a wider column, then all lines of the table must be modified (to maintain the tabular form) which is a larger change which leads to more effort to review and to understand the change at a later date
• Brittleness: if a programmer does not correctly format the table when making a change, the result is a visual mess that is harder to read than unaligned code. Simple refactoring operations, such as renaming, can break the formatting.
• More effort to maintain which may discourage a programmer from making a beneficial change, such as improving the name of an identifier, because doing so would require significant formatting effort
• Requirement to use a fixed-width fonts; not proportional fonts

Maintaining alignment can be alleviated by a tool that provides support (i.e. for elastic tabstops), although that creates a reliance on such tools.

As an example, simple refactoring operations to rename "$replacement" to "$r" and "$anothervalue" to "$a" results in:

$search=array('a','b','c','d','e');$r=array('foo','bar','baz','quux');$value=0;$a=1;$yetanothervalue=2;

With unaligned formatting, these changes do not have such a dramatic, inconsistent or undesirable effect:

$search=array('a','b','c','d','e');$r=array('foo','bar','baz','quux');$value=0;$a=1;$yetanothervalue=2;

White space

A free-format language ignores white space: spaces, tabs and new lines so the programmer is free to style the code in different ways without affecting the meaning of the code. Generally, the programmer uses style that is considered to enhance readability.

The following two code snippets are the same logically, but differ in white space.

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

versus

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

The use of tabs for white space is debatable. Alignment issues arise due to differing tab stops in different environments and mixed use of tabs and spaces.

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

intix;// Index to scan arraylongsum;// Accumulator for sum

Another programmer prefers tab stops of eight, and their toolset is configured this way. When someone else examines the original person's code, they may well find it difficult to read.

intix;// Index to scan arraylongsum;// Accumulator for sum

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:

classMyClass{intfoobar(intqux,// first parameterintquux);// second parameterintfoobar2(intqux,// first parameterintquux,// second parameterintquuux);// third parameter};

See also

• MISRA C  – Software development standard for the C programming language
• Naming convention (programming)  – Set of rules for naming entities in source code and documentation

References

1. "PEP 0008 -- Style Guide for Python Code". python.org.

External links

• Source Code Formatters at Curlie