WikiPage CodingStandards modified by John Malmberg

John Malmberg — Sat, 05 Jan 2013 18:11:30 -0000

Coding Standards

There are actually many coding standards that different projects use.

When making updates to a project being ported, you need to follow the standards that are in use for that project for those modules.

For new modules, it may not be obvious what coding standard to use.

In general though, the following guidelines are universal:

Almost universally banned

These almost always show up in coding standards as examples of what to never do.

Spaces after an open parenthesis
Spaces before a closing parenthesis
No space before or after a binary mathematical operator.
No space before an opening parenthesis for a conditional clause.
No space before a punctuation operator like a comma or period.

Line width

80 column maximum, actually about 79 characters may be preferred as a guideline. Most GUI based editors allow setting an indicator of where that line is.

An 80 column output can be read on most terminals, and the compiler listings from that will fit properly on terminals and printers in 132 character mode.

If you notice, newspapers tend to run narrow columns as they have found it is easier for people to read. (At least that is what I was told in elementary school), so keeping your lines short is preferred.

You can use temporary variables and refactor in to local subroutines to help keep lines shorter.

Tabs

Most projects are now banning hard coded tabs in text files because of the mess described below.

Actual TAB characters in code should only be used where the tab stops are on 8 character boundaries.

100 % of all terminals and printers commonly used by programmers, and most output formatting tools assume that Tabs are on 8 character boundaries, so when you use the TABs for 4 characters, your files look strange to everyone else that is not using your particular editor or IDE.

Unfortunately many of the early editor and IDE developers do not understand this basic fact have set the defaults to be 4 character TAB for GUI based environments. So you need to check before you save or publish code. Most of these environments now have features to convert TABs to equivalent spaces as one of their options.

The Python also assumes that TABS are on 8 character boundaries.

My personal preference is to use TABS on 8 character boundaries as I can move the cursor\ faster in the VMS EVE editor as I move across a line.

White space usage

The common convention is that white space should be between binary operators and not for unary operators.

Indenting

Indenting is now usually 4 characters with older conventions of 2 and 3 characters. If you see something larger than 4 characters it usually means that someone was using TABS set to 4 characters.

For DCL, I usually indent 3 characters from the leading $ on the line for the first indent
and then use 4 characters for each indent after, which allows TAB characters to be used.

On DCL there are two common conventions, no space after the initial $, or one space after
the initial $. I tend to prefer the no space.

Block Delimiters

For languages that take braces or other block delimiting tokens like C/C++/Perl the current convention for most new projects is that the opening delimiting token be on the same line as any code that references the block, and the closing delimiter be at the same
indentation as the statement where the block begins.

This compacts the code down so that more fits on a page.

That is per this example:

main() {
    if (foo) {
        bar(xx);
    }
}

Older conventions are to have the opening delimiter directly below and may have the
block delimiters with no indentation with respect to the block, or have the block delimiters that with either partial or full indentation.

Function declarations

For languages like C, there is a convention on some projects to have the return type and any qualifiers on a different line.

There is also a convention in declarations to put a space between the function name and the opening parenthesis, but not to put the space in where the routine is called. This is to make it so that searches for foo( find where a routine is called and searches for foo ( find where it is defined.

Trailing spaces

You may need to set your editor to not trim trailing spaces. This can cause unwanted white space changes in patches submitted.

Line endings

Most open source projects want line endings that are equivalent to stream LF. The GNV gnu diff utility will translate this properly for patches.

Diff will complain if your last line does not have a line terminator.

TODO: Add links to common coding standards.

Code Development

Recent changes to CodingStandards