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.