Style guide ad01
From Andreida
( there is another Style guide ad02)
operators and the like
curly brackets {}
- every curly bracket gets its own line. You may append comments if it makes sense, normally above or below is better
- the closing curly bracket is in the same column as the opening curly bracket
comments
- If you want the comment to stay - like documentation - use "///".
In Microsoft's Visual Studio you can set the display of "///" with "Tools/Options/Environment/Fonts and Colors/XML Doc Comment". You could change the "item background" to be able to read quickly through your documentation of your code.
naming
- Use camel case
- variables start with a lowercase letter
- methods/functions start with a lowercase letter
- classes start with an uppercase letter
Account accCustomerRemote = accountManager.getCustomerSpecial(CURRENTLY_LOGGED_IN);
variables
- prefix member variables with m_
- prefix static variables with s_
- prefix global variables with g_ (or don't use them)
- prefix variables with an indicator of the type (put it behind any m_, s_, g_)
- int* m_pnUserCount = ...
member | m_ |
static | s_ |
global | g_ |
natural numbers (int, long, ...) | n |
floating-point numbers (float, double, ...) | f |
string | s |
pointer (int*, char*, ...) | p |
enum | e |
combo box | cbo |
... |
constants
- in most cases do not use camel case here
- all upper case
- underscore "_" between "words"
header guard define
Consider using <NameSpace_ClassName> with camel case:
- the namespace lessens the chance of duplicate defines (you have no idea how many string.h or helper.h are out there)
- the camel case
- makes it easy to copy/paste from the file content to the define or use a macro to do it for you
- makes it easy to spot spelling errors
Example:
#ifndef FunnyCorp_Thing #define FunnyCorp_Thing namespace FunnyCorp { class Thing { public: protected: }; } /// namespace #endif