Always obey the rules, prefixed below by R. There will be a significant grade penalty for breaking them. Like grammatical mistakes in English, if you break the rules it is quite distracting, and may cause serious confusion for your reader.

Guidelines, prefixed below by G, should be generally followed or your program becomes hard to read, but violations are not as serious as breaking rules, and exceptions are sometimes appropriate.

1. R: Start every assignment file with a string identifying on its first line the assignment name, your lab section number (which you can find on the schedule page of the course web), and the names and usernames of all your assignment team members. For example:
   'a2, lab 1234, by Wilma Wiz (wwiz) and Harry Hacker (hhacker).
   If the assignment does not specify the program behavior, use a multi-line string with additional lines describing briefly how the program is used and what it does.
2. R: Python files (modules) may not do any I/O or launch a GUI while being loaded (executed)  or imported, except possibly after a "main()" call in the last line of the file. An easy way to check this is to comment out the main call (put a # mark before it) and then load the file with F5. If you see anything but a new prompt in the shell window, there is something wrong.
3. G: Use descriptive names for all identifiers (such as variable and function names). Generally avoid single letter names such as a and x. There are a couple times when short names are appropriate:
   • the identifier is being used as a index counter (in which case i and j are fine)
   • all uses are within a few lines of its declaration, and its declaration makes its significance clear.
     
4. R: Start variable names with lower case letters.
5. G: use either camel-case or underscores to separate the elements of compound names (for example, startingPoint or starting_point), but do not mix these styles in the same program.
6. G: Make good use of white space. Use a blank line to separate function definitions and to group closely related sets of instructions.
7. R: Indentation

   1. Use the same number of spaces for a unit of indentation throughout a program.
   2. NEVER use tabs. In the IDLE you can use the tab key, since with default settings it inserts spaces, rather than the tab character, but many editors do not do this. If you need a tab in a string literal, use its escape sequence. (Since different editors, printing methods, and the Python compiler, may interpret tabs in different ways, the only way to be sure that indentation will not be messed up by a different interpretation of tabs is to not use them.)
   3. Indent comments the same amount as the code they are commenting.

8. G: Use magic numbers only in variable declarations that give a name to the number. A magic number is any number other than -1, 0, 1, and 2. This forces you to give meaningful names to mysterious quantities, which goes a long way toward making programs self-documenting.
9. G: Use meaningful comments to clarify your program.
   • Provide comments for program characteristics that are not readily apparent from the names you have chosen and knowledge of common Python language mechanisms. Don't clutter up your program with comments that only says what is obvious from the code. Use of good variable and function names greatly reduces the need for comments.
   • String comments are preferred just after the start of a function and at the beginning of a module (file).
   • Use ## comments to indicate stubs and development notes (to be removed before the program is completed).
10. G: Clarity is almost always the overriding style concern.
    1. Avoid unnecessarily complicated code. Rework the code if you see a better way (called refactoring, another precept of extreme programming).
    2. Clarity is more important than efficiency, unless the efficiency improvement is important to the application. (For most "improvements" programmers are tempted to make in the name of efficiency, it is impossible to detect an efficiency improvement, and sometimes they actually slow the program down by making the compiler's job more difficult.
       
11. G: Break up long declarations. If a function is getting long (more than about 30 lines), it is often a good idea to break it up.