Mastering C++: Hungarian Notation, Modular Design, and Coding Style Guidelines
These guidelines detail C++ client-side naming conventions using Hungarian notation, modular and component-based development principles, and comprehensive coding style rules—including variable prefixes, class naming, indentation, brace placement, macro safety, and interface design—to promote readable, maintainable, and robust software.
Client-Side Code Writing Using Hungarian Notation
1. Prefix variable names with their type
e.g.,
int nCount; std::string strBuffer;2. Prefix class member variables with m_
e.g.,
int m_nCount;3. Prefix static variables with s_
e.g.,
static int s_nCount;4. Prefix global variables with g_ (generally avoid globals, use singletons or static members instead)
Do not use global variables unless absolutely necessary.
5. Prefix class names with C and capitalize the first letter
e.g.,
class CConfig6. For singleton classes, classes with only static methods, or objects unsuitable for copy construction, make constructors, destructors, and copy constructors private to prevent misuse
C++ Modular and Component Development Principles
1. Never place all functional code in a single executable
2. Export shared modules as dynamic libraries with clear interfaces; strictly separate low-level and logic layers
3. On Windows, compile dynamic libraries with the /MD option (do not use /MT )
Using /MD ensures all modules share the same heap pointer and dynamic library memory.
4. Export interfaces via a GetInterface function
class IInterface {
virtual void StartWork() = 0;
virtual void StopWork() = 0;
};
IInterface* GetInterface();5. Divide functionality among modules, interact through interfaces, and avoid putting all features into a single module for convenience
Basic Style Guidelines
1. Use a 4‑space or one‑tab indentation for code blocks
Auto‑generated code may have inconsistencies.
2. Write only one statement per line
Incorrect: rect.length = 0; rect.width = 0; Correct:
rect.length = 0; rect.width = 0;3. Place control statements ( if , for , while , switch , etc.) on their own lines and always use braces; put constants on the left side of comparisons
Incorrect: if (pUserCR == NULL) return; Correct:
if (NULL == pUserCR) {
return;
}4. Indent the bodies of functions, structures, loops, and conditional statements consistently; also indent case statements within a switch
5. Place braces ( { and } ) on separate lines aligned with the corresponding statement
Incorrect:
for (...) {
... // code
}Correct:
for (...)
{
... // code
}6. Add a space after commas and after non‑trailing semicolons
Example:
int a, b, c; for(int i = 0; i != 10; i++)7. Use parentheses to clarify operator precedence and avoid relying on default precedence
Example:
word = (high << 8) | low;
if ((a | b) && (a & c)) { ... }
if ((a | b) < (c & d)) { ... }8. Interface functions should validate the legality of their parameters, including pointer arguments
9. Enclose macro definitions in complete parentheses
Incorrect: #define RECTANGLE_AREA( a, b ) a * b Correct:
#define RECTANGLE_AREA( a, b ) ((a) * (b))10. Do not allow macro arguments to be evaluated multiple times
Incorrect:
#define SQUARE( a ) ((a) * (a))
int a = 5;
int b = SQUARE( a++ ); // a becomes 7Correct:
#define SQUARE( a ) ((a) * (a))
int a = 5;
int b = SQUARE( a );
a++; // a becomes 6Software Development Quality
Discussions on software development quality, R&D efficiency, high availability, technical quality, quality systems, assurance, architecture design, tool platforms, test development, continuous delivery, continuous testing, etc. Contact me with any article questions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
