Mastering C++ Naming Conventions: 8 Principles for Clear, Readable Code

1. Principle: True to Its Name

Choosing a name is a serious task; a good name matters.

If a name needs a comment to clarify, it’s not a good name.

The name must accurately express the concept and intent.

BAD:

int t = currentTime.elapse(e); // 消逝的时间, 以毫秒计

if (t > timeout_value) {

Zebra::logger->debug("---一次循环用时 %u 毫秒-----", t);

}

GOOD:

int elapsed_ms = currentTime.elapse(e);

if (elapsed_ms > timeout_value) {

Zebra::logger->debug("-----一次循环用时 %u 毫秒---", elapsed_ms);

}

2. Principle: Avoid Misleading Names

Do not leave clues that hide the true purpose of the code.

Avoid words that contradict the intended meaning.

Beware of names that differ by only a tiny detail.

Inconsistent spelling is misleading.

3. Principle: Make Meaningful Distinctions

Code is written for people, not just the compiler.

Numeric series like a1, a2, … are confusing.

Useless filler words such as a, an, the, Info, Data should be avoided.

BAD:

void copy(char a1[], char a2[]) {

for (size_t i = 0; a1[i] != ''; i++) {

a2[i] = a1[i];

}

}

GOOD:

void copy(char source[], char dest[]) {

for (size_t i = 0; source[i] != ''; i++) {

dest[i] = source[i];

}

}

4. Principle: Use Readable Names

Avoid overusing abbreviations.

Readable names facilitate communication.

5. Principle: Use Searchable Names

Avoid magic numbers.

Do not use single‑letter variables or high‑frequency short combos without clear purpose.

BAD: if (obj->base->id == 4661) { /* ... */ } GOOD:

#define OBJECT_FEEDBACK_CARD 4661

if (OBJECT_FEEDBACK_CARD == obj->base->id) { /* ... */ }

6. Principle: Avoid Encoding in Names

Hungarian notation (e.g., wdXX, dwXXX, strXXX) is outdated and often misleading.

Member prefixes like m_name are generally unnecessary.

7. Principle: Derive Names from the Problem or Solution Domain

Use terminology from the solution domain (e.g., AccountVisitor for a Visitor pattern implementation).

Use problem‑domain terms for features that map directly to game or business concepts.

8. Principle: Provide Meaningful Context

Group related classes, functions, and namespaces to give readers a clear context.

For a small number of variables, a prefix is fine; for many, consider encapsulating them in a struct or class.

Our C++ Naming Guidelines

File names: Capitalize the first letter; combine multiple words (e.g., SceneUser.h, Sept.h).

Class/namespace names: Capitalize each word; use nouns or noun phrases; avoid a leading “C” (e.g., SceneUser, SeptWar).

Function names: Start with a lowercase letter; use verbs or verb phrases; prefer methods inside classes or namespaces; common prefixes: get, set, is.

Variable names: All lowercase with underscores for multiple words; private members end with an underscore; avoid global variables when possible.

Good naming is a serious matter; it conveys concepts and intent, making code readable and maintainable.