forked from ComputationalRadiationPhysics/picongpu
-
Notifications
You must be signed in to change notification settings - Fork 0
Coding Guide Lines
Axel Huebl edited this page Jan 21, 2014
·
22 revisions
You are here: Developer Documentation > Coding Guide Lines
Help improving these guide lines!
- Indentation Depth: no TABS, but 2 or 4 spaces?
- References and Pointers are part of the Type (no space), e.g.
foo( int* i, float& b ) - functions and members like this? (@psychocoderHPC is for opt-in splitting type and compiler hints on separate lines if necessary)
template<class T_A> /* templates */
HDINLINE void /* type, compiler hints */
functionName( ... ) /* name params */
{
/* ... */
}-
TypeNamesandobjectInstances, e.g. definition ofEventTask 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
...; // commentas an inline comment
- prefer explicit
- 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)) constthis section will be moved somewhere else!
-
master->tags:alpha,beta,1.0 -
dev->release-...->master(tagged commit) -
topic-myNewFeatureorfeature-myNewFeature? fix-aHotfixName