A coding standard is an important part of programming. It lays the ground rules for how software is constructed and formatted . This standard has the following goals.
- Reduce the “holy shit” factor when faced with a lot of new code.
- Encourage a style of making software that is more maintainable and less likely to contain errors
- Make collaboration easier
All variable names shall be descriptive. The only exception is non-nested for loops, where the counter or iterator variable is ‘i’
All names shall be spelled correctly.
All names shall follow the camel case convention
Class variable names shall be a noun and start with a capital letter
Method or function names shall start with a verb and start with a lower case letter.
All non-class names shall start with a lower case letter
Constants shall be written in all capital letters delimiting words with ‘_’
Private class variables start with a ‘_’
All return variables start with a ‘r’
There shall never be two section (10 consecutive lines long) that have the same content. Content that breaks this rule should be re-factored into a separate function or method.
All methods shall only have one return statement. Instances that break this rule should use a single return variable to keep track of return information.
Nesting function calls as function parameters shall never go more than 3 levels deep.
Inline comments shall follow one of the following formats:
//–COMMENT–// comment string directly about code.
//–NOTE–// the note string. this is usually about an assumption or use case
//–TODO–// a item that still needs to be done or finished.
Documents, Files and Folders
All class shall be in separate files with the file name being consistent with the class name
All code files shall be back up on the source control server. The source control server shall never be more than 2 days out of date with any local copy.
Process and Convention
New code shall fallow the conventions and style of its current current base.
Keep method sizes small.
Test as much as is possible within the constraints given. Test first if possible. Application logic should be separated from application to application or application to environment functionality to promote testing.
All instances where this coding standard is intentionally broken shall be documented in a project centric location. This should include the files and methods breaking the standard, what parts of the standard is being broken, and why that part of standard is unable to conform.