1. Coding Standard: General Rules 1.Always be consistent with existing code. 2.Adopt naming conventions consistent with selected framework. 3.Use the same types as employed by the selected framework. 4.Do not use external API / libraries if the functionality is available in the selected framework.

2. Why Coding Standard? Code has to be -Readable -Well formed -Well commented -Well formatted -Well named -Self-consistent -Robust Disciplined coders achieve this by adhering to coding standards. Coding standards are specific to languages and frameworks, although there are some universal rules.

3. Naming Conventions 1.Use Pascal capitalization when naming types, global functions, and class members. 2.Use camel capitalization when naming local variables, function & method arguments. 3.Uppercase all preprocessor definitions (including types aliases and constants). 4.Use underscore to separate words in preprocessor definitions. 5.Use single-letter uppercase names for generic and template type parameters. 6.Use camel capitalization for template non-type parameters. 7.Prefix interface names with I. 8.Prefix MFC class names with C.

4. Naming Conventions, cont’d 9.Do not prefix managed class names with C or any other character. 10.Do not prefix user-defined type names. 11.Do not prefix user-defined type data member names. 12.Prefix MFC class data members with m_. 13.Prefix global variables with g_. 14.Never use Polish notation with managed and avoid Polish notation in unmanaged code. 15.Do not prefix managed class data member names with m_ or any other prefix. 16.Suffix subclass type with a name indicative of the base class if the subclass is derived from one of the following classes.

5. Naming Conventions, cont’d 17.Suffix delegate types with Handler. 18.Name event handlers as follows OnDelegateTypeLessHandler. 19.Use full words rather than abbreviations (unless using common abbreviations). 20.Do not combine more than three words in a name (unless shorter notation requires abbreviation or causes ambiguity). 21.Use only common single-letter variable names such as: -i, j, k for indexes -x, y, z for coordinates. 22.Name methods that perform an instance action with a single verb. 23.Name methods that perform a specific non-instance action with a verb-object combination. 24.Name methods that return a value as GetValue. 25.Never supply more than one output parameter. 26.Do not use namespace-qualified names, employ using namespace instead. 27.Use C++ built-in types rather than their System namespace equivalents.

6. Memory Allocation Rules 1.Always prefer static allocation to dynamic allocation. 2.Always use static buffers for data, which size has a manageable rigid upper bound. 3.Always check data size against the buffer size. 4.Never assume an arbitrary size limit for data that is in principle unlimited, use dynamic allocation in this case. 5.Always make classes dispose their allocated buffers on destruction. 6.Always check pointers for NULL before using them.

7. Class Instantiation Rules 1.Always use stack allocation to instantiate classes. 2.Always use local instances or references rather than pointers to represent class instances. 3.Always check class instance pointers for NULL before using them. 4.Whenever possible make initialize-from or create-from routines members of the class. 5.If an external initialize-from or create-from method is unavoidable use local stack allocation and rely on copy constructor to initialize an external instance with the local instance data.

8. Variable Usage Rules 1.Avoid global variables. 2.Define local variables as close as possible to the place of first use. 3.Always initialize local variables. 4.Store arguments of complex functional expressions in temporary variables. 5.Store return values of complex functional expressions in temporary variables.

9. Function Usage Rules 1.Never ignore function error codes. 2.Use executing braking rather than nested branching. 3.Do not use error codes, throw exceptions.

10. Flow Control Rules 1.Always provide default case in switch statements. 2.Do not fall through from one case statement to another. 3.Never use goto statement.

11. Constant Usage Rules 1.Never hardcode constants. 2.Avoid hard coding string literals that are presented to user. 3.Declare enumerations for variables with limited choice of values. 4.Declare enumeration types to be used in place of Boolean arguments for clarity. 5.Declare constants in managed classes as literals.

12. General Coding Rules 1.Never duplicate your code. 2.Never engage in cut and paste practice. 3.Document design decisions in common components. 4.Do not modify proven code. 5.Always test your changes.

13. Compiler Settings 1.Set compiler warnings to level 4. 2.Treat warnings as errors. 3.Always enable Code Analysis both for managed and C/C++ code.

14. Read Chapter 9 from my book.