Consistent C++ naming conventions make code easier to read, review, and maintain across teams and projects. By establishing clear rules for identifiers, you reduce ambiguity and help developers focus on logic instead of deciphering style.
This guide covers practical naming patterns, common conventions, and how to apply them in real codebases so that symbols clearly communicate their purpose and scope.
| Category | Recommended Style | Example | When to Use |
|---|---|---|---|
| Type alias | CamelCase with capital first letter | Matrix4f | Classes, structs, typedefs, using |
| Function | lowerCamelCase | computeSum() | Methods, free functions, lambdas |
| Variable | lowerCamelCase | userCount | Local, parameter, member variables |
| Constant / Macro | UPPER_SNAKE_CASE | MAX_BUFFER_SIZE | Macros, constexpr, const globals |
| Namespace | Lowercase, grouped by feature | audio::decoder | Logical module and library grouping |
Type and Class Naming Conventions
Capitalization for Types
Use CamelCase with an initial uppercase letter for types so they stand out in code reviews and documentation. This pattern works well for classes, structs, enums, and type aliases, giving developers an immediate visual signal that they are dealing with a type.
Enums and Scoped Values
Prefer strongly typed enums and group enumerators under the type name when possible. Use the same CamelCase style for enumerators or, in some teams, use an E prefix to make enum values easy to recognize at a glance.
Function and Method Naming
Verb-Based Names
Begin function names with a verb that describes the action, using lowerCamelCase for readability. For instance, parseConfig(), validateInput(), and sendFrame() clearly communicate intent and parameter expectations.
Boolean Getters and Setters
For accessors, use is for boolean getters such as isValid() or hasErrors(), and set or with for setters like setEnabled(bool) or withTimeout(int). Consistent naming here makes APIs predictable for users of your classes.
Variables, Constants, and Scope Indicators
Variable and Member Names
Use lowerCamelCase for variables and members, optionally including a short context prefix such as m for members or g for globals. This keeps related symbols visually aligned and supports quick scanning.
Constants and Macros
Name constants and macros in UPPER_SNAKE_CASE to make them immediately distinguishable from regular variables. This convention helps prevent accidental reassignment and clarifies the intended immutability.
Namespace and Directory Organization
Hierarchical Namespaces
Structure namespaces by feature or layer, using lowercase segments separated by ::, such as audio::decoder or graphics::vulkan::device. Clear namespaces reduce naming collisions and support modular architecture.
Adopting and Maintaining Conventions
Establishing rules is only the first step; teams need tooling and reviews to keep naming predictable and aligned with project standards.
- Document the chosen conventions in a shared style guide for new contributors.
- Use linters and formatters to flag deviations automatically during code reviews.
- Review naming decisions in design discussions to ensure clarity and consistency.
- Refactor symbols when context changes so names continue to reflect intent.
- Apply prefixes and suffixes sparingly to keep symbols easy to read and search.
FAQ
Reader questions
How should I name template parameters in C++?
Use concise, descriptive names like T for generic types or TT for template template parameters, and consider Tag types for policy parameters to communicate the role of the parameter.
What are best practices for naming private members?
Prefix with m or an underscore, such as m_buffer or _config, and keep the style consistent across the codebase so ownership and scope are clear at a glance.
Should I use Hungarian notation in modern C++ code?
Avoid type-based Hungarian notation, but limited form prefixes like m for members are acceptable if your team applies them consistently and transparently.
How do naming conventions interact with auto and generic programming?
Use auto for local clarity and keep naming consistent in interfaces; in generic code, rely on concept names and descriptive parameter names rather than encoded prefixes.