Coding Guide Lines

You are here: Developer Documentation > Coding Guide Lines

Help improving these guide lines!

• Indentation Depth: no TABS, but 2 or 4 spaces?
• functions and members like this?

template<class T_A>  /* templates */
HDINLINE void        /* type, compiler hints */
functionName( ... )  /* name params */
{
  /* ... */
}

General C++ Style Guide

• TypeNames and objectInstances, e.g. definition of EventTask myEventObject;
• use CamelCaseNames instead of in-name _ if not explicitly stated otherwise (e.g. fixed pre-/suffixes)
• comments
  • prefer explicit /* ... */ style
  • use Doxygen syntax for function/class description, choose the style /** \doxygenVariable ... */
  • you should avoid inline comments at all but you must not use ...; // comment as an inline comment
• braces on new lines (Yeah, East Coast Style!)

if( a == b )
{
   /* do something */
}

• ( ... ) are part of the caller (see above), no space to that caller but spaces to arguments inside
• same for template arguments: template< ... >
• close namespaces with a comment: } // namespace itsName
• Makros with newlines: align \ symbol to column 80
• Template Arguments shall be prefixed with T_:

template<typename T_ValueType, class T_SomeOption>
class XYZ;

• Describe how PreProcessor Macros are unrolled (excellent example)

/*      < typename T0, ... , typename TN    > */
template<BOOST_PP_ENUM_PARAMS(N, typename T)>
/*                      ( const T0, ... , const TN        ) */
HDINLINE void operator()( BOOST_PP_ENUM_PARAMS(N, const T)) const

Git: Naming Conventions for Branches

• master -> tags: alpha, beta, 1.0
• dev -> release-... -> master (tagged commit)
• topic-myNewFeature or feature-myNewFeature ?
• fix-aHotfixName

Auto-Testing via ?

• cppcheck
• vera++ (supports transformations -> auto-create pull request to pull request branch with proposed changes?)