CODING STANDARD
FOR COMPUTER PROJECTS
When you convert a design document into Python code, one of your primary
goals should be to write the source code and internal documentation in such a
way that it is easy to verify that the source code conforms to the design, and
that it is easy to debug, test, and maintain the source code. The coding
conventions listed below are designed to assist you in achieving this goal.
0. Guido's Style Guide
Guido, the creator of Python, has a lengthy style guide:
http://www.python.org/dev/peps/pep-0008/
1. NO NAME OR PID
Every project is submitted to a cheat-check program which is done off campus
so to protect your privacy do NOT include your name or PID.
2. File Prologue
Each source code file will contain an introductory block of comments that
identifies lab section and assignment. For example:
/****************************************************************************
Section 1
Computer Project #5
****************************************************************************/
3. Main Prologue
The prologue for the main function contains a high-level algorithm
for the main function. Keep it short. For example:
# Algorithm
# 1. Prompt for an integer
# 2. Input an integer
# 3. Loop while not end-of-file
# a. call digits funtion passing integer input as an argument
# b. output the digits
# c. prompt for another integer
# d. input an integer
# 4. Output a closing message
4. Function Prologue
Using docstrings (deliminted by triple double-quotes) each function will
contain an introductory block of comments that explains the purpose of the
function and describes all information passed to the function
(parameters and global data objects). In addition, an algorithm for the
function must be provided. For example:
"""
Count the number of digits in an integer value.
Receive: The integer value to be processed
Return: The number of digits in that value
Algorithm:
1. set the digit count to zero
2. loop while integer value parameter is greater than zero
a. increment digit count
b. update value to be the quotient of value divided by 10
3. return the digit count
"""
5. CamelCase Mnemonic Identifiers
Meaningful identifiers that are taken from the problem domain will be used for
all names. Use camelCase style. In addition, a name will not be used for
more than one purpose.
fahrenheitTemp = 0.0 # Temperature in degrees Fahrenheit
celsiusTemp = 0.0 # Temperature in degrees Celsius
6. Symbolic Constants
Symbolic constants will be used instead of embedding arbitrary numeric and
character constants in the body of functions. For example:
HEAT_OF_FUSION = 79.71 # Calories to melt one gram of ice
7. Descriptive Comments
Comments that describe the functionality of blocks of code will be included
within the body of each function. Comments are particularly important before
all blocks of code that perform major data manipulations or error processing.
8. Source Code Format
All source lines will be less than 80 characters in length.
Only one statement will be included on a given line of the source code.
Blank spaces and blank lines will be used to enhance the readability of both
source statements and comments.
Use four spaces for indentation.
Control structures will not be nested too deeply. If the clarity of the
source code is impaired by too many levels of nesting, the statements that are
nested most deeply will be removed and placed in a separate function.