Codestyle

Code-style

Code-style is established to unify core creation, simplify code support and navigation. Code-style is mandatory in all cases, except for the situation when is directly reduces readability and the ability to understand code. Latter however is quite a broad opportunity for an author to protect her/his view on the codestyle, as long as the author supports the piece of code on his/her own.

However code-style is not enforced for a while and now is more like a really strong recomendation.

Indentation

In С/С++ files indentation of 4 whitespaces should be used in most cases. It is allowed to indent and beautify code, tables, lists with additional spaces if it improves readability. Tabulations (\t) are prohibited in all source code files, except for the ones that need it (i.e. Makefile)

Reason for this is that the author of the code could use indentation as a way to emphasize the semantics of the code, and this need to be preserved regardless of the code reader IDE setup.

Line endings

CoreCVS uses UNIX line endings ("\n").

File naming

С/С++ files are named with camelCase, with lowercase first letter. The reason for this is to more effectively use autocomplete in the command line. If filename starts with abbreviation all abbreviation letters are used in lower case.

Example:

• rgbBuffer.cpp
• graphPlotDialog.cpp

Naming of the Classes and methods

• Classes and structures should be named starting with capital letter, using CamelCase. It is discouraged to use prefixes such as TClass, CType, etc.
• Functions and methods should be named starting with lower case letter, using CamelCase.
  • Only exception here are static methods that return the class instance. Because they are semantically close to named constructors, they are also named starting with capital letter.
• Variables are always named starting with lower case letter. This incluedes local variables, global variables and parameters.
  • In the classes that implements mathematical notions it is fine to use mathematical notation. I.e - it is fine to name Matrix A and distinguish it from the matrix element a.

Expression and language construction sequence

It is preferred to always put curly brackets after if, for, while/do statement. Even if it encloses a single line statement. For the long blocks of code put the bracket in the next line. For small ones it is occasionally fine to leave it in the same line as the condition. Rule of thumb is - if the code block could be caught and hold in the brain as a single entity, it is ok to put the bracket in the same line as the statement.

• There should be a white-space between if for while switch and the opening bracket.
• White-space should also be put after ; inside for.
• Unary, binary and ternary operators should be surrounded by whitespace.

Example

for (int i = 0; i < 10; i++) {
    printf("Num=%d\n", i);
}

Avoid creating code lines longer than 120 symbols

Exceptions

Think twice before using exceptions over return values. Use exceptions only in the really exceptional situation.

Code complexity

Try to minimize cyclomatic complexity.

So:

• goto is ok if serves the function of exiting and cleaning up resources C-style.
• Multiple return points from function are fine.

Git usage