Naming convention

Use US English (GCG14001)

All identifiers (Types, member, parameters, variables etc.) should be named using words from the US English language.

• Names should be easily readble, preferably grammatically correct names.
  Example: HorizontalAlginment is better than AlignmentHorizontal.
• Favor readability over brevity.
  Example: CanScrollHorizontally is better than CanScrollHorizontally.
• Avoid using names that conflicts with keywords from widely spread used programming languages.

Use proper notation for language elements (GCG14002)

Depanding on the used programming language the proper notation for language elements such as classes, method and variables should be used. Widely spread casings are camel case, pascal case, snake case and kebab case.

Don't include numbers in varfianles, parameters and type members (GCG14003)

In most cases these kind of names are lazy excuses for not defining a clear and intention-revealing name. Often they are used instead of collections.

Don't use prefixes (GCG14004)

Types, type members, parameters, variables etc. shouldn't include a prefix to define the scope or type. Known prefixes are g_ for global, s_ for static or string, i_ for integer and _ for private members.

In some programming languages it is not possible to obey this rule. Many languages uses _ for backing fields, other to communicate that a member is private.

Don't use abbreviations (GCG14005)

Abbreviations like btn for button and cmd for command harm the readability and intelligibility. Avoid single character variable names, such as i or q. Use index or query.

Exception: Use well-known acronyms and abbreviations that are widely accepted or well-known in your work domain. For instance, use acronym UI instead of UserInterface and abbreviation Id instead of Identity.

Name members, parameters and variables according to their meaning and not their type (GCG14006)

The name should describe the functionality and not their type.

Identifiers that refer to a collection type should have plural names.

Name types using nouns, noun phrases or adjective phrases (GCG14007)

Naming	Example
noun	IComponent
noun phrase	ICustomAttributeProvider
adjective phrase	IPersistable

Name methods using verbs or verb-object pairs (GCG14008)

Naming	Example
verb	Show
verb-object pair	ShowDialog

The name should describe the what, and if possible, the why.

Name generic type parameters with descriptive names (GCG14009)

Always prefix type parameters with the letter T for Type.

The name should describe the what.

Name members similarly to other members in the used programming language or framework (GCG14010)

To let developers, who are already familiar with the used programming language or framework, finding their way into your project, you should use a naming pattern which is widely used by the language or framework.

Avoid short names or names that can be mistaken for other names (GCG14011)

Although technically correct, statements like the following can be confusing:

bool b001 = (lo == l0) ? (I1 == 11) : (lOl != 101);

Don't repeat the name of a class or enumeration in its members (GCG14013)

class Employee
{
    // Wrong!
    static GetEmployee() {...}
    DeleteEmployee() {...}

    // Right
    static Get() {...}
    Delete() {...}

    // Also correct.
    AddNewJob() {...}
    RegisterForMeeting() {...}
}

Avoid class containing terms like Utility and Helper (GCG14013)

Class containing terms like Utility or Helper are usually static classes and are introduced without considering object-oriented principles.

Avoid method names containing the word and (GCG14014)

A methods containing the word and implies, that it is doing more than one thing, which violates the Single Responsibility Principle.

Präfixen von booleschen Variablen und Member (GCG14015)

Prefixing of boolean variables and members (GCG14015)

To make boolean variables and members more descriptive consider prefixing them with Is, Has, Can, Allows or Supports.

---

Last update: 2021-09-26