wast within control

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 with examples from the Fortran and PL/I languages 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.


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'); //Another example $value = 0; $anothervalue = 1; $yetanothervalue = 2; with: $search = array('a', 'b', 'c', 'd', 'e'); $replacement = array('foo', 'bar', 'baz', 'quux'); //Another example:
         $value = 0;
  $anothervalue = 1;
$yetanothervalue = 2; 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.


In those situations where some whitespace is required the grammars of most free-format languages are unconcerned with the amount that appears. Style related to whitespace is commonly used to enhance readability.

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

int i; for(i=0;i<10;++i){

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


The use of tabs to create white space presents particular issues 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.

int ix; // Index to scan array long sum; // Accumulator for sum

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

int ix; // Index to scan array long sum; // Accumulator for sum

Solutions to this issue may involve forbidding the use of tabs or rules on how tab stops must be set.

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
  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
  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 < 24) && (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 equals sign (=) for assignment and a double equals sign (==) for comparison (e.g. C/C++, Java, PHP, Perl numeric context), and most languages in the last 15 years, and where assignments may be made within control structures, there is an advantage to adopting the left-hand comparison style: to place constants or expressions to the left in any comparison. Here is the left-hand comparison style applied to a line of Perl code:

if ($a == 42 ) { ... } # A comparison checking if $a equals 42. if (42 == $a ) { ... } # Recast, using the left-hand comparison style.

The difference occurs is when a developer accidentally types = instead of == (see example below). The first line now contains a fault (i.e., it sets the value of $a to be 42 rather than comparing it with 42). The second line contains a semantic error (i.e., numeric values cannot be assigned to) that will result in a diagnostic message being generated when the code is compiled.

if ($a = 42 ) { ... } # Inadvertent assignment which is often hard to debug if (42 = $a ) { ... } # Compile time error indicates source of problem

Some languages have built-in protections against inadvertent assignment, e.g. Java and C# do not support automatic conversion to boolean for just this reason.

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("%dn", 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 %dn", i);
   printf("%dn", i*2);    /* The incorrect indentation hides the fact that this line is not part of the loop body. */
printf("Ended loop");


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[] = {
    "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. However, this technique can result in a syntax error (or misleading semantics) in some languages. Even for languages that do support trailing commas, not all list-like syntactical constructs in those languages may support it.

See also


External links

Coding conventions for languages

Coding conventions for projects

Search another word or see wast within controlon Dictionary | Thesaurus |Spanish
Copyright © 2014, LLC. All rights reserved.
  • Please Login or Sign Up to use the Recent Searches feature