Style guide ad02

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
c-string (null terminated)	sz
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

Access Specifiers

Everything goes into protected.
Then you move the ones you need in public to public.
Normally developers don't need private.

That does not mean to not use "private:". It just means, put everything in protected first and only if you realize that derived classes should not be able to use that member variable or method, THEN you move it to private.

Every time you move a member variable to the public area you will get a shock and hear a voice which shouts "Encapsulation".

Starter

• Keep in mind that no access specifiers mean
  • public for structs
  • private for classes
• Separate definitions which use multiple lines by empty lines from the others
• Group methods and variables with empty lines by logic, context or whatever makes sense to you

Sequence

You should have your access specifiers in this sequence:

1. public
2. protected
3. private

Reason: think about other users of your class. Why should someone who can only access the public part of your class have to read through protected and private member variables and methods?

This is the normal usage. If you use certain environments (like the Unreal Engine) you might NEED or want to start with a private part, as you'll see in the example below.

separate methods and member variables

Use the access specifiers multiple times to have areas for member methods and other areas for member variables.

Example

class Base
{
  GENERATED_BODY()

  public:
    Base();

  protected:
    void normalMethod1(void);
    void normalMethod2(void);

    FMulticastDelegateSignature& getDelegateLightsOff();

  protected:
    int m_nCountErrors;
    std::string m_sCurrentInsult;
    std::vector<std::string> m_vecListOfInsults;

    UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = Input)
    UInputAction* m_pLookAction;

    FMulticastDelegateSignature m_mcdLightsOff;
};

Look at

UInputAction* m_pLookAction;

Pure logic tells me to use

UInputAction* m_pActionLook;

or something like that. But I decided otherwise.
Why? Because I like it more that way. We are developers, not slaves :-)