Coding style naming - Godlike/Unicorn GitHub Wiki

Quick links:

Naming

Consistent naming helps with code readability in a direct way.

Names shall be short and descriptive and, as most of other stuff, self-explanatory.

Files and directories

We will only mention naming conventions here, the directory layout will be covered later.

  • Filenames shall be in UpperCamelCase
  • Directory names shall be in lower_case_with_underscores
  • Ideally directory names shall consist only of one word
  • Header files shall have .hpp extension
  • Source files shall have .cpp extension
  • Template implementation files shall have .imp extension

Variables and macros

  • Variables shall be in lowerCamelCase
  • If variable contains abbreviations, they should follow lowerCamelCase rule
  • Variables shall not contain underscores unless the underscore is a part of prefix
    • Public class variables shall not be prefixed
      • If public variable is used as a proxy to some other class' functionality, it can use Method's naming conventions instead of variable naming conventions
      • If public variable is a pointer, it shall use pointer's prefix
    • Protected and private class variables shall be prefixed with m_
    • Static class variables shall be prefixed with s_
    • Global static variables shall be prefixed with g_
    • Pointer variables shall be prefixed with p in addition to any other prefixes they may have
    • Variables shall not contain any other prefixes (i.e. Hungarian notation)
  • Macros shall be in UPPER_CASE_WITH_UNDERSCORES
  • CMake variables **shall be in UPPER_CASE_WITH_UNDERSCORES
Example code 
#define Stringify(x)    #x                      //! BAD: UpperCamelCase
#define UNICORN_EXPORT __declspec(dllexport)    //! GOOD

int i;              //! OK: general name for a counter
bool g_running;     //! OK: global flag that may be accessed from other files
float f;            //! BAD: undescriptive name
float cameraFOV;    //! BAD: uppercase abbreviation

class XmlParser     //! GOOD: abbreviation
{
public:
    // ...

    EmptyCallback OnDone;   //! GOOD: public proxy to some callback

private:
    static bool s_rdy;  //! BAD: unnecessary shortening

    bool valid;         //! BAD: no prefix

    void* m_buffer;     //! OK: no pointer prefix, but OK since it's a general name
    uint32_t m_sz;      //! OK: but m_size would be better

    Content* m_ptr;     //! BAD: not descriptive name
    File* m_pFile;      //! GOOD

    multimap<string, Node*> m_stringNodeMap;    //! BAD: too descriptive
                                                //!      m_nodes would've been better
};

Classes and namespaces

We will only mention naming conventions here, the namespace nesting and class design will be covered later.

  • Class names shall contain a noun
  • Class names shall be in UpperCamelCase
  • Namespaces shall be in lower_case_with_underscores
  • Ideally namespaces shall consist only of one word
Example code 
namespace Parsers   //! BAD: UpperCamelCase
{
namespace markup_language   //! OK: but maybe unnecessary ¯\_(ツ)_/¯
{

class Check;        //! BAD: verb instead of a noun, not descriptive
class Validator;    //! GOOD

}
}

Methods and functions

To make it easier to understand what are you refering to we suggest to distinguish between methods and functions as follows:

  • Function is independent and does not rely on external variables when operating on its inputs
  • Method is a function that is related to a class. Static methods are still considered methods if they work with static class variables.

Naming conventions:

  • Method and function names shall contain a verb
  • Method and function names shall be in UpperCamelCase
Example code 
void ProcessFromMemory(void* buffer, uint32_t size);    //! GOOD: UpperCamelCase
bool isValid() const;   //! BAD: lowerCamelCase
bool IsEof() const;     //! GOOD: UpperCamelCase and abbreviation
                        //!       IsEOF() would've been OK since it's a widely used term
⚠️ **GitHub.com Fallback** ⚠️