One more naming convention for C++

Lot of discussion about what should be the proper naming convention for C++. Bjarne Stroustrup has recommended the following approach, which is useful as advice:

Name a variable (function, type, whatever) based on what it is or does. Choose a meaningful name; that is, choose names that will help people understand your program. Even you will have problems understanding what your program is supposed to do if you litter it with variables with easy-to-type names like x1, x2, s3, and p7.

Abbreviations and acronyms can confuse people, so use them sparingly.
Acronyms should be used sparingly. Consider, mtbf, TLA, myw, RTFM, and NBV.
They are obvious but wait a few months and even I will have forgotten at least one.

Short names, such as x and i, are meaningful when used conventionally; that is, x should be a local variable or a parameter and i should be a loop index.

Don’t use overly long names; they are hard to type, make lines so long that they don’t fit on a screen, and are hard to read quickly. These are probably ok:

partial_sum    element_count    staple_partition

These are probably too long:

the_number_of_elements    remaining_free_slots_in_symbol_table

I prefer to use underscores to separate words in an identifier (e.g, element_count) rather than alternatives, such as elementCount and ElementCount.
Never use names with all capital letter (e.g., BEGIN_TRANSACTION) because that’s conventionally reserved for macros. Even if you don’t use macros, someone might have littered your header files with them. Use an initial capital letter for types (e.g., Square and Graph).

The C++ language and standard library don’t use capital letters, so it’s int rather than Int and string rather than String. That way, you can recognize the standard types.

Avoid names that are easy to mistype, misread, or confuse. For example

name    names    nameS
foo     f00
fl      f1       fI       fi

The characters 0, o, O, 1, l, and I are particularly prone to cause trouble.

Often, your choice of naming conventions is limited by local style rules. Remember that maintaining a consistent style is often more important than doing every little detail in the way you think best.

Let’s take that one step further, I took this advice and a Google’s Code style recommendation and I compiled the following simplified guide, considering that there is the freedom to define some custom bast based on good practise lie Goolge’s reccomendation.

Hope that helps

Filenames should be all lowercase and can include underscores (_).
Examples of acceptable file names:

C++ files should end in .cpp and header files should end in .h

Type names start with a capital letter and have a capital letter for each new word, with no underscores: MyExcitingClass, MyExcitingEnum. The names of all types — classes, structs, type aliases, enums, and type template parameters — have the same naming convention.

For example:

// classes and structs
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...

// typedefs
typedef hash_map<UrlTableProperties *, std::string> PropertiesMap;

// using aliases
using PropertiesMap = hash_map<UrlTableProperties *, std::string>;

// enums
enum class UrlTableError { ...

Variable names
The names of variables (including function parameters) and data members are all lowercase, with underscores between words. Data members of classes (but not structs) additionally have trailing underscores. For instance: a_local_variable, a_struct_data_member, a_class_data_member_.

  • Common Variable names
    For example:

    std::string table_name;  // OK - lowercase with underscore.
    std::string tableName;   // Bad - mixed case.

  • Class Data Members
    Data members of classes, both static and non-static, are named like ordinary nonmember variables, but with a trailing underscore.

    class TableInfo {
      std::string table_name_;  // OK - underscore at end.
      static Pool<TableInfo>* pool_;  // OK.

  • Struct Data Members
    Data members of structs, both static and non-static, are named like ordinary nonmember variables. They do not have the trailing underscores that data members in classes have.

    struct UrlTableProperties {
      std::string name;
      int num_entries;
      static Pool<UrlTableProperties>* pool;

Constant Names
Variables declared constexpr or const, and whose value is fixed for the duration of the program, are named with a leading “k” followed by mixed case. Underscores can be used as separators in the rare cases where capitalization cannot be used for separation. For example:

const int kDaysInAWeek = 7;
const int kAndroid8_0_0 = 24;  // Android 8.0.0

Function Names
Regular functions have mixed case; accessors and mutators may be named like variables. Ordinarily, functions should start with a capital letter and have a capital letter for each new word.


(The same naming rule applies to class- and namespace-scope constants that are exposed as part of an API and that are intended to look like functions, because the fact that they’re objects rather than functions is an unimportant implementation detail.)

Accessors and mutators (get and set functions) may be named like variables. These often correspond to actual member variables, but this is not required. For example,

int count()
void set_count(int count)

Namespace Names
Namespace names are all lower-case. Top-level namespace names are based on the project name. Avoid collisions between nested namespaces and well-known top-level namespaces.

The name of a top-level namespace should usually be the name of the project or team whose code is contained in that namespace. The code in that namespace should usually be in a directory whose basename matches the namespace name (or in subdirectories thereof).

Enumerator Names
Enumerators (for both scoped and unscoped enums) should be named like constants, not like macros. That is, use kEnumName not ENUM_NAME.

enum class UrlTableError {
  kOk = 0,


Naming in Google C++ code guide