Code Standards

1. The cyclomatic complexity—V(g)—of any method shall never exceed 15 under any circumstances. The cyclomatic complexity of any method may only exceed 10 when there is valid justification explained in the design specification or in the code itself.
2. The fan out of any method shall never exceed 10 under any circumstances. The fan out of any method may only exceed 5 when there is valid justification explained in the design specification or in the code itself.
3. The depth of decision nesting of any method shall never exceed 6 under any circumstances. The depth of decision nesting of any method may only exceed 4 when there is valid justification explained in the design specification or in the code itself.
4. Inheritance hierarchies shall not be more than 4 levels deep unless justified in either design documentation or in source code comments.
5. When inheritance is used, the subclass operations can require no more, nor guarantee any less, than any super-class operation they override (aka “Liskov Substitutability”).
6. Programmers (and designers) should strive to apply good code structuring principles: abstraction, encapsulation, cohesion, coupling, favor association over inheritance, design to invariant/design for change, avoid premature optimization.
7. Operation names shall describe everything that the operation does (without revealing how it does it). Vague, uninformative names like “calc()”, “handle input()”, etc. must be avoided.
8. Variable names shall explain the meaning and the role of the information held in that variable. Vague, uninformative names like “status”, “flag”, and “i” must be avoided.
9. All individual source code files should be limited to about 250 lines of code.
10. In conjunction with deleting an object, all references to that object shall be set to a NULL reference or modified to reference valid objects. Exception: references that immediately go out of scope are exempt.
11. All source code files shall have a header that identifies the file, establishes a reference to the design specification where appropriate.
12. Design-by-Contract shall be used—all operations shall have an explicitly defined contract specified in that operation’s comment block, and that contract shall be consistent with the method implementation.(See template below)

Operation-level Source Code File Template

[public or private] <return-type> <operationName> ( [param list] ) {

// Description

//  <provide a quick summary level description of the operation>

// Requires

//  <define all relevant preconditions here>

// Guarantees

//  <define all relevant postconditions here>

// Secrets

//  <list any secrets here>

  <declare any local variables here>

  <implement the method code here>

}