Many of the assignments will used software that comes with the text by Hanson or the text by Bryant and O'Hallaron. Some assignments will require you to measure and analyze the way programs behave: how long they take to run, and so on.
The course will also have two exams: a midterm and a final.
Excellent documentation will address exactly the key issues, and degree of detail will be exactly appropriate.
Excellent code will be very well thought out and implemented. Representations and their invariants will be well documented in the code itself. Invariants will be protected by assertions. Excellent code will show evidence of thorough attention to abstraction and modularity. Excellent code will be so simple that it obviously has no faults. Instructors will see no obvious ways to make excellent code shorter or simpler. Layout will be consistent and will make good use of scarce vertical space. Excellent code will be of such high quality that the course staff would be happy to maintain it.
Very good documentation will address most key issues, with a good amount of detail.
In Very Good code, representations will be well documented but some invariants may have been overlooked. Key assumptions (non-null pointers, non-zero divisors) will be validated by assertions. Invariants may be validated. Individual functions will be well organized and readable. Some attention will have been paid to abstraction and modularity, although one or two opportunities may have been overlooked. Nevertheless, very good code will maintain a single point of truth (see Don't Repeat Yourself) for properties of algorithms and data structures. Instructors may see one or two ways to make code shorter or simpler. Layout will be consistent and will make good use of scarce vertical space. Small errors may be evident from reading the code.
Good documentation will cover some key issues, but significant issues may have been overlooked or may have been covered with insufficient detail. Vague generalities may appear where precise specifics are expected.
In Good code, representations will be documented, but documentation may not be up to expectations. Some assertions will be present, but perhaps not as many as should be. Individual functions will be well organized and readable. Opportunities for abstraction and modularity will probably have been overlooked: representation may be exposed unnecessarily, too many unrelated functions may have been gathered in one file, or both. Command-line processing may be mixed with program abstractions. The code may not always maintain a single point of truth for properties of algorithms and and data structures, but duplication will be minimal. Good code will get the job done, but possibly in a way that could be shorter or simpler. Layout may be inconsistent in a few places. Errors may be evident from reading the code, but instructors will believe that code could be made correct with only modest changes.
Fair documentation will show evidence of effort, but the degree of coverage and detail will be significantly short of what the course staff believe is needed to foster success.
Fair code will contain significant faults. Representations may be undocumented. Instructors may not be able to figure out what all functions do. Layout may be inconsistent or waste scarce vertical space (e.g., every other line may be blank). Fair code may show evidence of a 'clone and modify' approach to program construction. Possibly a Fair program could be replaced by code half its size. Given Fair code, instructors may believe major changes would be required to make the code correct, or instructors may be unable to understand why the code might be correct.
Poor documentation may fail to address key issues or may address them perfunctorily.
Poor code may be undocumented or inappropriately documented (e.g., overcommented). Poor code will often be lengthy out of all proportion to the problem being solved. Poor code may be laid out on the page in a way that is hard to read. Poor code often shows evidence of its history: extra copies of functions, unused logic left lying around, old code commented out, and so on. Poor code may be so complex that it has no obvious faults.
You will receive No Credit for work that you cannot explain.
No Credit will be received for work that is deemed to be plagiarized. Code submitted for Comp 40 may be examined for potential plagiarism using automated heuristics. Plagiarism is a form of academic fraud, which is unacceptable at Tufts. If academic fraud is suspected, appropriate steps will be taken.
Each exam consists of multiple problems; you may be expected to read and write code. Each problem is worth a certain number of points; the number depends on how hard I think the problem is and how long it takes to complete the problem. Most problems are in multiple parts of varying difficulty:
Every exam is unique, but on average, if you earn two-thirds of the available points, your grade will probably be Good or Very Good.
This weighting may be adjusted at my discretion.
Participation in classroom activities 8% Homeworks and labs 64% Midterm exam 8% Final exam 20%
When determining final course grades, I consider the total picture including not only all of your work but any grading tendencies I have observed during the term. My goal is the final course grades should reflect a consistent standard, consistently applied.
In a typical class, a consistent record of Very Good homework, together with commensurate examination grades, will lead to a course grade in the A range. If a significant portion of work is rated Excellent, a grade of A+ is possible. Work rated Good corresponds to a wide range of passing grades centered roughly around B. Work rated Fair will lead to low but satisfactory course grades; if a significant fraction of your work is Poor, you can expect an unsatisfactory grade (D or F).