 |
|
|
No tabs are to be used in the source code. |
|
|
All indentations must be to four (4) spaces to indicate scope. |
|
|
Line continuations are to be indented to more than eight (8) spaces as to differentiate the line continuation from scope levels . |
|
|
All braces "{}" must be on a single line with no other code and Not be indented at the same level as the contents inside. |
|
|
Only one executable statement per line is to be used in any source file . |
|
|
Comments must be descriptive and not restate the obvious. |
|
|
No comment boxes are to be used. |
|
|
Comments should begin in column one (1) with the "/*" and the wording in a comment should begin in column four (4). |
|
|
Lines of source code should not exceed 80 columns. |
|
|
The use of negative operations should be avoided. |
|
|
The "C" language should not be extended through the use of macros (i.e. forever and unless). |
|
|
Variable declarations must be aligned by variable name by placing the first alphabetic character in each variable name in the same column. |
|
|
Variable names must start with a lower case letter and use a capital letter for the first letter of each following word or abbreviation (i.e. localVariableName). |
|
|
All files must include the Company copyright along with the description, author, filename, date created, and modification history at the beginning of the file. |
|
|
No underscores "_" are to be used in variables, typedefs, or structures. |
|
|
Definition Macros must be in Upper Case with underscores "_" following the prefix (if there is one) and underscores between each word or abbreviation. |
|
|
Code Macros must be in lower Case with underscores "_" following the prefix (if there is one) and underscores between each word or abbreviation. |
|
|
Variable names must be chosen so that they are meaningful. If abbreviations are used, the meaning MUST be clear and unambiguous. |
|
|
All constants MUST be defined in a Macro. |
|
|
ANSI "C" compliance will be followed with full function prototypes. |
|
|
All project function prototypes will be located in a single header file. |
|
|
Global Variables will be defined in a single file for each project. |
|
|
The const type will be used for all static tables. |
|
|
"C" types should not be explicitly used except for compatibility issues. |
|
|
Header Files will not be nested. |
|
|
All return codes will be checked and dealt with accordingly. |
|
|
The default case in a switch statement will NEVER be left blank. |
|
|
All fall through case statements will be documented with comments as to why the fall through needs to occur. |
|
|
Error Checking should always be done on anything that might go awry (i.e. overflow, multithreaded access to pointers, etc.). |
|
|
32 bit and 16 bit values will always be fully aligned (even in linked lists). |
|
|
A compile of the code should produce No Warnings. |
|
|
Any variable declared must be used, unless it is declared as a parameter in state machine functions and is not used in every state function. |
|
|
Pointers are always declared with a pointer type not the asterisk (*). |
|
|
Global Variables are prefixed with "tv" (i.e. tvSystemTicks). |
|
|
Static/Local variables are prefixed with "tl" (i.e. tlCountVariable). |
|
|
Typedef types are prefixed with "tt" (i.e. ttListType). |
|
|
Function names are prefixed with "tf" (i.e. tfGetValue). |
|
|
Structure names are prefixed with "ts" (i.e. tsListStruct). |
|
|
Union names are prefixed with "tu" (i.e. tuParameterUnion). |
|
|
Macros are prefixed with "TM_" (i.e. TM_MAX_BYTES). |
|
|
Macro code is prefixed with "tm_" (i.e. tm_lock). |
|
|
Pointers are postfixed with "Ptr" (i.e. listPtr). |
|
The only exception to these naming conventions is when a specification or RFC requires otherwise. |
