Computer Systems Organization (CSCI-UA-0201.001/002)
Spring 2014 -- Section 1 (Honors) and Section 2
Professor: Andrew Case
General .:. Schedule .:. Assignments .:. Resources .:. Help
There are two primary components that assignments will be graded by: correctness and style. Despite being technically correct, your assignments must also adhere to certain style guidelines. Below is the division of points between the two.
Note: If an auto-grader is provided that validates your solutions, it will only report back whether the code is correct; a meatbag will deduct points according to coding style later on.
Code Correctness - 75% (unless otherwise stated)
This will include:
- Does it compile? If it doesn't you automatically lose 50%.
- Does it meeting all assignment requirements?
- Does your assignment handle edge cases (i.e. is it comprehensive)?
- Does it catch errors (i.e. is it robust)?
Coding Style - 25% (unless otherwise stated)
This will include:
- Code Readability - adhering to these policies makes your code easier to understand and maintain.
- Your code should be self-docummenting. By self documenting, we mean: do your variable names describe what they store; do your procedure names describe what they do? For example, 'x' is almost never a good name (asside from cartisian coordinates) for a variable as it is unclear as to what is stored in 'x'. A better name might be 'averageGrade' so that someone reading the code would immediately know what was stored in the variable. Procedures perform some kind of action and so they should be named to describe what that action is. For example, 'boolean test(int foo)' isn't a good specification for a function since we don't know what this procedure is testing or what the variable 'foo' stores. A specification might be 'boolean isPrime(int number)' as it's immediately apparent that this function returns true if 'number' is prime, otherwise it will return false.
- Avoid hardcoding values. When using an arbitrary value, pull those values out of your programming logic and into a constant/variable that describes that data. This makes the code easier to comprehend, more modular, and easier to update in the future if those values should change.
- Proper comments - this does not mean you should comment every line of code. More comments do not necessarily mean a better grade; excessive commenting of obvious code can make a program equally unreadable. In fact, if you use self documenting code, needs for inline commenting will be limited. All functions and classes should have block comments however that describe their purpose/arguments/output. Inline comments should be concise and used to clarify non-obvious sequences of code or design decision.
Commenting code is more of an art form than a scientific study. See these articles related to commenting practices (which all give reasonable input to the idea of balancing extraneous commenting with adequate documentation):
tl;dr: comments should be concise; use inline comments sparingly (when possible use self-documenting code); document functions with a description, inputs, outputs, and side-effects
- Consistency - once you choose a style of code, please stick with it. This applies to:
- naming of functions/variables/etc. (e.g. myVariableName vs my_variable_name)
- spacing (around operators and between functions), indention, and tab usage
You will be graded on consistency, not which style you choose, but it may be worthwhile to practice using some of the industry standard coding styles (i.e. PEP8 for Python, the Java Code Conventions by Oracle.)
Most IDEs have utilities to help. For example, Eclipse has a code formatter utility built-in and we provide a formatter specification for it to use. Take advantage of it:
- To add formatter file to Eclipse: "Preferences -> Java -> Coding Style -> Import"
- Hot key for applying formatting to code: "Ctrl+Shift+F" (Windows) or "Command+Shift+F" (Mac)
- Elegance - does your algorithm include a lot of unnecessary work or brute force calculations? Is it patched together haphazardly without clear organization or purpose? Do you use excessive memory or will your algorithm be exceedingly slow?
These requirements are based on Marsha Berger's original grading criteria.
© 2010-2014 Andrew I. Case