Style guide ad01

From Andreida

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