New version page

PSU CSE 420W - Coding Standard General Rules

Upgrade to remove ads
Upgrade to remove ads
Unformatted text preview:

Coding Standard: General RulesWhy Coding Standard?Naming ConventionsNaming Conventions, cont’dSlide 5Memory Allocation RulesClass Instantiation RulesVariable Usage RulesFunction Usage RulesFlow Control RulesConstant Usage RulesGeneral Coding RulesCompiler SettingsReadCoding Standard: General RulesCoding Standard: General Rules1. 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.Why Coding Standard?Why Coding Standard?Code has to be-Readable-Well formed-Well commented-Well formatted-Well named-Self-consistent-RobustDisciplined coders achieve this by adhering to coding standards.Coding standards are specific to languages and frameworks, although there are some universal rules.Naming ConventionsNaming Conventions1. 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.Naming Conventions, cont’dNaming Conventions, cont’d9. 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.Naming Conventions, cont’dNaming Conventions, cont’d17. 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.Memory Allocation RulesMemory Allocation Rules1. 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.Class Instantiation RulesClass Instantiation Rules1. 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.Variable Usage RulesVariable Usage Rules1. 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.Function Usage RulesFunction Usage Rules1. Never ignore function error codes.2. Use executing braking rather than nested branching.3. Do not use error codes, throw exceptions.Flow Control RulesFlow Control Rules1. Always provide default case in switch statements.2. Do not fall through from one case statement to another.3. Never use goto statement.Constant Usage RulesConstant Usage Rules1. 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.General Coding RulesGeneral Coding Rules1. 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.Compiler SettingsCompiler Settings1. Set compiler warnings to level 4.2. Treat warnings as errors.3. Always enable Code Analysis both for managed and C/C++ code.ReadReadChapter 9 from my

View Full Document
Download Coding Standard General Rules
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...

Join to view Coding Standard General Rules and access 3M+ class-specific study document.

We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Coding Standard General Rules 2 2 and access 3M+ class-specific study document.


By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?