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.
totalSum=a+b+c+
d+e;
method(param1,param2,
param3);
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,1,-sinAngle);
matrix.setElement(2,2, cosAngle);
// Apply rotation
transformation.multiply(matrix);
- 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();
} }
Statements
- 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.
const long ERROR_UNDEFINED_VARIABLE=1;
- 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;