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.