Style guide ad01

( 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 = ...

variable prefixes

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