Assignment Resources

• Java Style Guide
• Specifications
• Java Q & A
• Turn-In
• Documentation
• Java 1.3 API

Grading policy

All members of a team are usually given the same grade for the team project. The grade includes both written materials -- specifications, design and code -- as well as oral presentations and constructive participation in review sessions.

To encourage participation in reviews in the first half of term, teaching assistants can award significant credit (up to 20% of the final grade) for constructive contributions during review sessions. The total portion of the grade allotted to exercises and participation is capped at 50% of the total grade, but using participation credit, it is possible to achieve a perfect score despite points lost on written exercises.

Your written work will be graded on the quality of the ideas and the quality of their presentation. Code will be judged by its clarity, organization, style and correctness. It is the student's responsibility to demonstrate to the grader that the code is correct by showing the results of running a test suite. In the absence of such evidence, graders will assume that code is not correct. This is the standard you would be held to in industry. If there is no appropriate output to show, you should add a comment stating that a test suite executed successfully (or not, if it didn't).

We make every effort to standardize TA grading policies, but we reserve the right to normalize grades across recitation sections to account for remaining disparities.

Late/Missing work

Late work will receive no credit. Exercises are due at 4.05pm on Wednesdays in the course secretary's office (NE43-529). In unusual or extenuating circumstances (such as illness with a doctor's note), you may be able to turn in an exercise late and still obtain credit for it. Unless the circumstances are quite extraordinary, you must receive advance permission from your TA.
You must hand in: Exercise 4, and one of Exercise 5 or 6, and the project or you will fail the course. You will not pass the course if you receive no credit for these, or if what you hand in is too insubstantial to be deemed a reasonable effort. Grades of "incomplete" will not be given, except under extraordinary circumstances.

Collaborative Work

The Departmental Guidelines Relating to Academic Honesty require that we inform you of our expectations regarding permissible academic conduct.

You may discuss any of the course material with other students. You may discuss the exercises, and you may talk about potential solutions with other students, whether or not they currently enrolled in the class. What you hand in, however, must be entirely your own work (with the exception of reused code -- see below). You will be expected to be able to explain your work during reviews in front of other students, so it will be necessary for you to understand your solution to any problem in every detail. In particular, you must not copy explanations, written answers to questions, design diagrams, source code, or test cases from other students, in whole or in part.

Throughout the course, you may make use of any software artifact -- specifications, design, algorithms or code -- in the public domain , so long as it was not prepared by a student for 6.170. For example, you can use code you find in textbooks and on the web, but you can't copy code from your fraternity's bible. For the project, you are encouraged to collaborate with your teammates on all aspects of the work, although every member of the team will be expected to contribute equally to the design and implementation. We will expect the team to be able to account for what each team member contributed to the project. The same policies that apply to individual students during the first half the term also apply to the project teams. For instance, a team can discuss design ideas with another team, but must not copy any of its design models. 'Pair programming' is permitted for the project, but is strictly forbidden for the individual exercises.

This policy is more lenient than it has been in previous terms, in an attempt to foster constructive collaboration amongst students. We therefore depend on the honesty of students in not violating it, and will take very seriously even minor infractions. If you are found to have copied code from another student's work, you should expect to fail the course.

We rely on students' honesty in their declarations that test suites run successfully. It is a very serious violation of academic ethics to submit such a claim with code that does not in fact pass the suite. In order to avoid clerical errors that may give the appearance of dishonesty, we strongly suggest that you rerun all your test suites when you have completed your code immediately prior to submission.

Procedures

Handouts

Handouts will be distributed on the class web site. Announcements will be posted as "Messages of the Day" on the class website. Very important announcements will be emailed to all students.

Graded Assignments

Graded assignments will generally be returned to you in the review session in the week after they were due.

Exercise Hints

To complete the exercises as efficiently as possible, and to derive the most benefit, we recommend that you:

• Start as early as possible. Elapsed time helps.
• Read the entire text of the assignment before starting any part of it.
• Don't rush to code. You'll find that the more time you spend on design, the less time you spend coding (and much less time debugging).
• Write test cases before you code. This avoids the pitfall of thinking about the code as you write your tests, which could cause you to overlook the same issues in your testing as you did when writing the program. You may want to add additional test cases after writing the code, of course, particularly if implementing the specification brought issues to your attention that you had not been aware of before you started coding.
• Don't debug aimlessly: you'll waste a lot of time and get frustrated. Instead, form a hypothesis and devise an experiment to check it.
• If you're stuck, leave your computer for a while. You may well find that clearing your head allows you to see an obvious problem that you'd missed before because you were focused on the (wrong!) details. When you're tired, stop.
• Make sure that your answers to questions are succinct and to the point.