evilissimo/naming-things
Reviews and improves **names** in code — variables, functions, classes, modules, parameters — for clarity, intent, and consistency with language/team conventions. Triggers when asked to review names, rename things, improve code readability, clean up confusing code, or when examining code with generic/vague names like "data", "info", "manager", "temp", "util". Does NOT trigger for general code review unrelated to naming, architecture design, debugging, or performance optimization. Identifies naming anti-patterns (generic names, misleading names, type-encoding, abbreviations), suggests role-based names that reveal intent, checks consistency with project/domain vocabulary, and flags misalignment with language culture.
91
90%
Does it follow best practices?
Impact
94%
1.05xAverage score across 5 eval scenarios
Passed
No known issues
cpp.mdreferences/
C++ Naming Conventions
C++ has more variation in naming conventions than most languages because of its long history, multiple major style guides, and lack of a single official formatter. Always check the project's existing style first.
Major Style Guides
| Guide | Convention | Domains |
|---|---|---|
| Google Style | snake_case for variables/functions, PascalCase for types | Chromium, Google projects |
| LLVM/Clang | camelCase for variables, PascalCase for types | LLVM, Clang, Swift |
| Boost | snake_case with _t suffix for types | Boost libraries |
| Qt | camelCase methods, PascalCase classes prefixed with Q | Qt framework |
| Microsoft | PascalCase for public, camelCase for private with m_ prefix | Windows, .NET interop |
| Standard Library | snake_case, lower-case types | std::vector, std::sort |
Convention Table (Most Common — Standard Library + Google-Influenced)
| Thing | Convention | Example |
|---|---|---|
| Variable | snake_case | user_name, total_count |
| Function / method | snake_case | calculate_total(), get_user() |
| Class / struct / enum | PascalCase | CustomerOrder, HttpClient |
| Template parameter | PascalCase | template <typename T> |
| Macro | SCREAMING_SNAKE_CASE | ASSERT_TRUE(x), PI |
| Constant / constexpr | kPascalCase or SCREAMING_SNAKE | kMaxRetryCount, BUFFER_SIZE |
| Namespace | snake_case | order_processing, net::http |
| Member variable | snake_case_ (trailing _) or m_snake_case | name_, m_count |
| Getter / setter | snake_case matching member | name(), set_name() |
| Boolean predicate | is_ / has_ / can_ prefix | is_empty(), has_next() |
Key Points
- The most important rule: follow the project's existing convention, not your personal preference
- Private member variables commonly use trailing underscore (
name_) orm_prefix (m_name) - Getters usually drop
get_:user.name()notuser.get_name() - Setters use
set_prefix:user.set_name("Alice") - Boolean functions use
is_,has_,can_:container.is_empty(),socket.has_data() - Avoid
_prefix for private members — reserved for implementation by the standard - Macros are
SCREAMING_SNAKEand should be rare — preferconstexpror templates - Template type parameters: single uppercase for simple cases (
T,K,V),PascalCasefor descriptive (TEntity,Allocator) - No Hungarian notation — modern C++ doesn't use
strName,pBufferprefixes autotype deduction doesn't change naming rules — still name by role
Common Offenses
| Bad | Good | Reason |
|---|---|---|
char* pszName | std::string name | Legacy Hungarian; modern C++ uses types |
void DoSomething() | void do_something() or void ProcessOrder() | Pick one style and stick to it |
int tmp | int scratch / int buffer_size | tmp doesn't express role |
obj / ptr | item / node / handle | Type-encoding without meaning |
data | records, entries, results | Generic — what data? |
i, j, k outside loops | index, row, col | Fine for loops; bad for wider scope |