Common Style Guidelines and
Program Requirements
PRINCIPLE 1: PROGRAMS AND FUNCTIONS SHOULD BE WELL STRUCTURED:
a) Use a modular approach for a complex problems
b) Use only the basic control structures when developing each code segment. (Each
segment should be entered at the top and have only one exit.)
c) Use local variables within functions when the variable is used only within that function.
d) Use parameters to pass information to and from functions. NO global variables.
e) To protect arguments that should not be modified by a function, declare the parameters
to be value parameters or constant reference parameters rather than reference
parameters.
f) Don’t use “magic numbers.” Constant identifiers should replace integer literals.
g) Strive for simplicity and clarity. Clever programming tricks should be avoided when
clarity is compromised.
PRINCIPLE 2: ALL SOURCE CODE SHOULD BE DOCUMENTED:
a) Each program MUST include opening documentation.
b) Comments should be used only to explain key code segments, reading these comments
by themselves should give a clear version of the subject of the code.
c) Do not use documentation that restates the obvious. It tends to serve no purpose other
than to clutter the program for the reader.
d) Use meaningful identifier names. NO abbreviations unless standard.
e) Used mixed-case for variables with more than one word in the name, do not use
underscore.
f) variables and functions start with a lower case letter. User-defined types start with upper
case.
PRINCIPLE 3: SOURCE SHOULD BE FORMATTED IN A STYLE THAT ENHANCES READABILITY:
a)
b)
c)
d)
e)
Put each statement of the program on a separate line.
Put each { and } on a separate line.
Align each { and it corresponding } . Indent the statements enclosed by the { and }.
When a statement is continued from one line to another, indent the continued lines.
Align the identifiers in each constant and variable declaration, placing each on a separate
line.
f) Insert blank lines between declarations and statements and between blocks of
statements to make clear the structure of the program.
g) Declare constants and variables at the top of a function.
h) All variable and function identifier names should use complete words unless the
abbreviations are well known and understood. All variable and function names start
lower case and capitalize each letter of each subsequent word, no underscores.
i) All constant identifiers are ALL CAPS with an underscore separating words.
j) All class and structure identifiers start upper case and capitalize each subsequent word,
no underscores.
k) Label all output produced by a program.
PRINCIPLE 4: USE STANDARD NAMING CONVENTIONS FOR FILES IN A MULTI-FILE PROGRAM.
a) Use consistent naming conventions for the multiple files that comprise one package.
b) The x.h file should contain the specifications for the data.
c) The implementation of the data (member functions) should be stored in a separate x.cpp
file.