StyleGuide

back to home

Style Guide for Developers

The rules for CFS are quite relaxed - only a few items are mandatory to follow. Further guide lines are kind of common sense and might be worth discussing.

Mandatory rules

• Use no tabulators but spaces instead!!!
  • Be aware the the default setting for Eclipse are tabs.
• Use indentation 2.
• Use only 7-bit ASCII, check for umlaute as grep --color='auto' -P -n "[\x80-\xFF]" file.xml
• CMake commands must be lowercase

Supported Systems

As of the CFS++ developer meeting 4./5.11.2015 in Wien we decided about the following rules:

• we may use C++11! (this implicitly depreciates too old compilers!)
• We support restrict compiler support to gcc >= 4.8 and Intel >= 15
• supported systems are
  • ScientificLinux
  • CentOS
  • openSUSE (FAU)
  • Ubuntu (FAU)
  • Windows (via crosscompiling)
  • Mac OS X (whoever takes care about it)

Good Coding Style (personal view!)

Naming conventions

• Class and Function names should start with capital letters
  • class NonLinBlaBla;
  • void CalcDMat();
• The file names should follow the containing class names with the same upper and lower letters
  • NonLinBlaBla.hh and NonLinBlaBla. cc
• Private attributes have a tailing underliner
  • bool valid_;

CMake

• Keep CMake files as simple as possible

Meta-Coding issues

• Try to avoid to much includes in header files, use forward declarations when possible
• Use the Logging feature and do leave out commented cout statements.
• Document your stuff
  • in Doxygen
  • in this Wiki
  • in the XML Reference
• Please, for heaven's sake - don't do copy & paste but extract common functionality to own methods or use object oriented programming techniques!
• Avoid too long functions and classes - this helps to structure the problem.

Hints and Tricks

• Instead of a long if/then/else(if) chain use a switch statement when dealing with a enum.
  • when there is no default statement the compiler prints a warning when the enum gets more values.