The code you write for this course is expected to be of consistently high quality. This includes both its functional aspects, i.e. correct and reliable behavior that meets the objectives of the task, and its style, i.e. clarity, readability, and maintainability.

This course will not require adherence to any particular precise, detailed programming style guide. Instead, we will evaluate the style of your code based on the based on basic principles outlined below.

1. Don't repeat yourself. Source code in which the same information appears in multiple places can be difficult to understand and, therefore, to debug.
   1. If you find yourself repeatedly copying and pasting a block of code, even with small modifications each time, you should probably write a function to abstract that block. Duplicated code is notoriously difficult to maintain.
   2. If your code contains explicit “magic numbers” or other constants that are repeated or copied from some documentation somewhere, you should replace those explicit values with named constants. This is especially true if those values appear more than once in the code.
2. Write for your audience. The “audience” for your source code includes (a) you, (b) other humans including your instructor, (c) your future self, and (d) your compiler or interpreter. Therefore, your goal should be to write code that is both functionally correct and easy for humans to read, understand, and maintain.
   1. Tell the truth. Select names that accurately describe the data or code that they refer to. Ensure that comments correctly describe the code they document.
   2. Explain yourself. Write comments for each non-trivial function explaining its purpose and clarifying anything that's not obvious about how it works. More complex functions may benefit from documentation for smaller sections of code as well.
   3. Reveal the organization. Insert white space to make the structure clear. Use blank lines where appropriate to group related sections of code.
   4. Be consistent. Use predictable conventions for naming things, designing function parameters, formatting code, etc. This makes it easier for human readers to understand how the components of a program fit together.

Lastly, a word of unsolicited advice: Don't fall into the trap of writing bad code with the intention of “fixing” it meet these general guidelines after it works. By doing that, you'll experience the all of the pain that comes from satisfying these constraints, but miss out all of the benefits.