You are here: Home Service Coding Style & Conventions

Coding Style & Conventions


General Recommendations

  • Check for errors early and often. Return from errors immediately.
  • Have you checked for compiler warnings? Warnings often point to real bugs.
  • Use an efficient debug output implementation through a macro statement, a function call or an object method.
  • If possible reduce object and file dependencies. Eliminate needless import or include statements.
  • All identifier, names and comments should be written in English.
  • Check again for warnings or errors before committing source code.


Source File Structure

  • Source file names should have the right suffix: .c .h .cpp .cxx .java etc.
  • Use Unix-style carriage returns ("\n") rather than Windows/DOS ones ("\r\n").
  • File content should be kept within 80 columns (for laptop side-by-side diffing, two-window tiling or hardcopy printing).
  • Special whitespace characters like TAB and page break must be avoided.
  • Avoid non-ASCII characters and use a standard encoding scheme (e.g. UTF-8).
  • Break lines after a comma or an operator. Align the new line with the beginning of the expression on the previous line.


setText("Long line split"+
         "into two parts.");
  • Reserved words, colons and semicolons should be and operators may be surrounded by a space character.
  • Apply 1..4 spaces as indentation per logic level. Note that class visibility and goto labels do not consume a logic level.
  • Logical units within a block should be separated by one blank line.
// Create a new identity matrix
Matrix4x4 matrix=new Matrix4x4();

// Precompute angles for efficiency
double cosAngle=Math.cos(angle);
double sinAngle=Math.sin(angle);

// Specify matrix as a rotation transformation
matrix.setElement(1,1, cosAngle);
matrix.setElement(1,2, sinAngle);
matrix.setElement(2,2, cosAngle);

// Apply rotation
  • Parentheses after function names and terminating semicolons have no space before them.
  • Use either the // or /*...*/ syntax for comments, as long as you are consistent.
  • There should be a space after the starting comment identifier.
  • All comments must follow the documentation rules for your project.
  • For JavaDoc comments use the following form.
 * Return lateral location of the specified position.
 * If the position is unset, NaN is returned.
 * @param x    X coordinate of position.
 * @param y    Y coordinate of position.
 * @param zone Zone of position.
 * @return     Lateral location.
 * @throws IllegalArgumentException  If zone is <= 0.

public double computeLocation(double x, double y, int zone)
  • Start with a one-line caption (as precise as possible) followed by a more detailed description.
  • When using a software repository, omit tags like @author, @version or @change-date.
  • Insert TODO in a comment to flag something that has to be implemented.
  • Use FIXME to flag something that is currently bogus and broken.
  • Comments should be indented relative to their position in the code.
while (true)           // NOT:  while (true)
{                               { 
  // Do something               // Do something
  something();                     something();
}                               }



  • Type conversions must always be done explicitly. Never rely on implicit type conversions (C/C++ only).
  • Array specifiers must be attached to the type not the variable (Java only).
  • Variables should be initialized where they are declared (C/C++ only).
  • Variables should be declared in the smallest scope possible.
  • Variables must never have dual meaning.
  • Class variables should never be declared public.
  • Variables should be kept alive for as short a time as possible.
  • Complex conditional expressions should be avoided. Consider evaluation functions or methods.
// BAD:
if ((elementNo<0) || (elementNo>maxElement)|| elementNo==lastElement) {...}

// GOOD:
if (isFinished(elementNo,maxElement) || isRepeatedEntry(elementNo,lastElement)) {...}

boolean isFinished(int num, int max) {return((num<0) || (num>max));}
boolean isRepeatedEntry(int num, int last) {return((num==last));}
  • The usage of confusing expressions with non-obvious side effects must be avoided (e.g. comma operator).
  • Floating point constants should always be written with decimal point and at least one decimal.
  • Always write { ... } to properly enclose simple statements (e.g. after for/while/then/else keywords).
  • It is a good idea to use parentheses liberally to avoid operator precedence problems. Even if it seems clear to you.
if (a==b && c==d)     // AVOID
if ((a==b) && (c==d)) // RIGHT


Naming Conventions

  • Use "interCaps" and leading-lowercases for all identifiers (if syntactically possible).
long updateStatusBar();
  • Use Java-Style Constants. The name should be all uppercase, with underscores between words.
  • Abbreviations and acronyms should not be uppercase when used as name.
exportHtmlSource(); // NOT: exportHTMLSource();
  • The name of the object is implicit, and should be avoided in a method name.
line.getLength();   // NOT: line.getLineLength();
  • Complement names should be used for complement entities.
get/set, add/remove, create/destroy, start/stop, insert/delete,
increment/decrement, old/new, begin/end, first/last, up/down, min/max,
next/previous, old/new, open/close, show/hide, suspend/resume, etc.
  • Abbreviations in names should be avoided.
computeAverage();     // NOT: compAvg();
ActionEvent event;    // NOT: ActionEvent e;
  • Negated boolean variable names must be avoided.
boolean isError;   // NOT: isNoError
boolean isFound;   // NOT: isNotFound
  • Respect the projects rules for prefix characters to variable names.
g (global)   => g_DataLen       // outside of class namespaces (C/C++ only)
s (static)   => s_PrefChecked   //
m (member)   => m_Length        //
  • Associated constants (final variables) should be prefixed by a common type name.
final int COLOR_RED=1;
final int COLOR_GREEN=2;
final int COLOR_BLUE=3;