CS242 Collaboration Policy

General Philosophy

We are confident that all of you have come to Stanford planning to respect and uphold the Honor Code. In order to support you in that effort, we would like to define what is and what isn't considered acceptable collabration, so there is no ambiguity. The general premise of our policy is that your submissions must be your own independent and original work. You should not give or receive any aid which makes the assigned tasks significantly easier. We do allow for discussion and help among students, but expect you to document any significant help that you received. On our part, we will treat you with trust and will protect the honorable student's interests by investigating and prosecuting dishorable behavior.

Collaboration on Coding Projects

Things that are always allowed

These things are encouraged and allowed at all times for all students.

• Discussing material covered in lecture or handouts.
• Discussing the requirements of an assignment.
• Discussing features of any programming language.
• Discussing how to use the tools or development environments.
• Discussing general techniques of coding or debugging.
• Any discussion between the student and a CA. You are welcome to discuss any and all ideas, design, code, debugging, and details with the course staff. They are the best folks to talk to because they are knowledgable about all the material and know how to help you without giving away the farm. They also have the authority to give you definitive answers to your questions.

Collaboration that is allowed if documented

Two students engaging in a more detailed discussion of specifics can cross into the area of collaboration that is acceptable only if documented. We require that you include the name of those whom you received specific assistance from and properly credit their contribution, as you would cite a reference in a research paper. Some examples:

• Discussing the design of the project. Design is a crucial part of the programming process, and discussion can be valuable, but you should take care to document any design input you got from others.
• Helping another student debug their code. In general, we prefer that you get this sort of help from the CAs, but if you do get detailed debugging advice from someone, you should credit their assistance.
• Sharing advice about testing. For example, if someone tells you a lesson learned ("our program didn't handle the case where the input file didn't end with a newline") that you then use to improve your program's robustness, you should credit them for providing you with that insight.

Collaboration that is NOT allowed

• Copying code is the most blatant violation. You should not be copying anyone else's work. You should also not allow anyone else to copy yours. You should keep your work secure.
• Using work from past quarters. Using someone's work or solutions from a previous quarter is an obvious violation.
• Studying someone else's code. You should not be reading anyone else's code whether it is on the screen or written out by hand.
• Debugging someone else's code. Debugging along with someone makes it too easy to look over their code and allow (sometimes unintended) code-copying. Describing to someone a problem and asking for advice on how to track it down is okay, but you should do the actual debugging yourself.

Closing Thoughts

Above all you should use your common sense. If you suspect that what you are about to do is a violation, play it safe and ask a staff member first rather than take risks with your academic career.

The Honor Code is taken very seriously in this course and we have no tolerance for behavior that falls outside our boundaries for acceptable conduct. Please do your part in maintaining a community where academic work is done with a high standard of integrity!

Some parts of this document are derived from a collaboration policy for Brown's CS courses.