Written Homeworks

Written homeworks in this class are provided primarily as an opportunity to get things wrong, to reinforce topics in lectures and the readings, and as a template for what to expect on exams. They will be marked according to the following simple rubric:

• 5: Solution is completely correct, concisely presented, and neatly written.
• 4: The solution is mostly correct, but one or two minor details were missed, or the presentation could be more concise.
• 3: The main idea is correct, but there are some significant mistakes. The presentation is somewhat sloppy or confused.
• 2: A complete effort was made, but the result is mostly incorrect. There may be some basic misunderstandings of the topic or the problem.
• 1: The beginning of an attempt was made, but the work is clearly incomplete.
• 0: Not submitted

Coding Style

Your coding style will be judged in three categories: readability, documentation, and organization. The purpose is to get in the habit of producing high-quality, understandable, maintainable programs. Keep in mind that there are many audiences for the code you write: the compiler or interpreter, programmers familiar with your code (including yourself in the future), and programmers unfamiliar with your code (including your instructor).

We usually focus on getting correct code, treating on the compiler or interpreter as the primary audience. This may be reasonable, but remember that source code will also be reviewed by humans — including yourself in a week or a month or a year from now. Following the guidelines below will help make sure that the human readers and maintainers of your code are well-informed and happy.

Readability

• 5: Code is sensibly, cleanly, and consistently formatted. Vertical whitespace and comment lines are used to separate significant components of code, and proper indentation is used consistent with the standards of the language. This indentation renders properly with standard 8-space tabs, and no lines exceed 80 characters in width.
• 4: Code is mostly readable but there are a few inconsistencies or "broken rules".
• 3: Lack of vertical whitespace, inconsistent indentation, or improper formatting make the code difficult to read at times.
• 2: Significant sections of code have little or no helpful whitespace, or do not follow any standard formatting conventions.
• 1: No attempt at readability. It seems almost as if the author is intentionally trying to obfuscate their code.
• 0: Nothing submitted.

Documentation

• 5: Authors' names and purpose of file are summarized at the top of the file. Sensible names are chosen for all variables, functions, classes, and so on, consistent with naming conventions for the language (such as capitalizing ClassNames in Java or ending Scheme predicates? with a question mark). When not obvious from the names, the role of each function, method, and class is stated alongside the definition. Extra comments are included to explain especially tricky or involved sections of code.
• 4: Documentation includes all required elements, but some details or explanations make parts of the code difficult to follow. Some names may be chosen poorly.
• 3: A few functions or classes lack sufficient documentation. Names do not always follow conventions or convey meaning to aid in understanding. Some tricky sections of code are not explained.
• 2: Most required documentation is missing or lacking in quality.
• 1: Almost no documentation in comments, and most names do not help in understanding the code.
• 0: Nothing submitted.

Organization

• 5: Appropriate control structures (functions, classes, recursion, loops, etc.) are used as appropriate to the language and the style of coding. Code is written in a modular fashion, without unnecessary inter-dependencies. Control structures are used to eliminate lengthy copied or nearly-identical sections of code. When possible and appropriate, standard libraries are utilized to avoid "reinventing the wheel".
• 4: Overall code organization is adequate, but some sections of code are repeated, or some beneficial uses of control structures are missed.
• 3: Some control structures are under-used or used inappropriately. Some dangerous, deprecated, or ill-advised features such as global variables or go-to statements may be used without good cause.
• 2: Significant sections of code are poorly organized. Basic principles such as information hiding, loose coupling, and modularity are mostly ignored.
• 1: Little evidence of organization present. Significant sections of code may be copied or unreachable. Useful and obvious language features appropriate to the task are ignored, and dangerous features are over-used.
• 0: Nothing submitted.

Oral Presentations

For the oral presentations in Part III of your project, we will follow the CS department's standard rubric.