- Pascal Van Hentenryck, Professor of
CS, Brown University, 1997
Half of your course grade (and pretty much all of your learning)
comes from doing the assignments. We can talk about Java all day in
lecture and section, but you will only truly absorb the material after
spending some quality one-on-one time with the language and tools. The
programming assignments are non-trivial and you will find them
time-consuming and sometimes frustrating.
We also hope you will find the work to be rewarding and that you will be
proud of your accomplishments and the new skills that you will gain.
We do believe it is important that you do your own independent work
on the assignments. However, that doesnt mean that it shouldnt be
possible to get help or talk to anyone else when you get stuck.
We definitely want you to be able to succeed in your endeavors, but
would like to be clear about what is and what isnt considered
We are confident that all of you have come to Stanford planning to
respect and uphold the Honor Code. In order to make you successful in
upholding your end of the bargain, we need to be very clear about what
we expect from you. The basic premise of our course policy is that you
should do your own thinking, your own design, and your own coding. You
should never let yourself be led by another student, or receive an
amount of help which makes an assignment significantly easier.
Conversely, you should never assist another student in a matter that
would overly lead them or make their job much easier.
On our part, we will treat you with trust and will protect the
honorable students interests by investigating and prosecuting
Things that are allowed
These things are encouraged and allowed at all times for all students.
- Discussing material covered in lecture, section or the text.
- Discussing the requirements of an assignment.
- Discussing features of the Java language.
- Asking questions about syntax or specifications. For example: Is strcmp case-sensitive?
What does the keyword static do here?
- Discussing general techniques of designing, coding, or debugging. Saying
things like It worked well to test each function right after
I wrote it,
or When my programs crashes, I first look at the stack trace
in the debugger, is fine.
- Discussing features of any of the programming tools or development
- Any discussion between the student and a section leader or TA. 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 knowledgeable 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
Whereas high-level abstract discussions are always allowed, two
students engaging in a more detailed discussion of a particular design
decision or a student helping another to track down a particularly nasty
bug will cross into the area of collaboration that is acceptable only if
We require that you include the name of any student(s) who you received
such assistance from and properly credit their contribution to your
work. This is akin to acknowledging a reference in a research paper.
- Discussing the design of an assignment. Design is a crucial part
of the programming process, and discussing it is very
valuable. However, learning to work through design problems on
your own is a skill which requries time and practice. Try to work
out as much as you can on your own, but discussion amongst
students is okay, as long as it is documented.
- Helping another student to debug a particular problem. Two students
should not sit down and debug jointly, but one might give the other
some direct hints (e.g. when I had a similar problem, it was
because I had forgotten to put a terminating null on my linked
list). In general, we prefer that you get this sort of help
from the TAs (who know better how to guide you without going
overboard), but if you do get detailed debugging advice from
someone, you should credit their assistance.
- Sharing advice about testing. For example, if your roommate tells you
about some lesson learned (my program didnt handle the case
where the input file didnt end with a newline) that you then
use to improve your programs robustness, you should credit your
roommate for providing you with that insight.
Collaboration that is NOT allowed
Basically, the rule is that you should be handing in code which
represents your original, independent work.
It should not be based on, influenced by, or copied from anyone elses.
- Copying code. This is the most blatant violation. You
should not be writing down anyone elses code, or allowing anyone
else to write down your code.
- Using work from past quarters. Using someones work or
solutions from a previous quarter is an obvious violation.
- Looking at someone elses code. You should never read
anyone elses code whether it is on the screen or written
out by hand.
- Debugging with another person. Sitting at the same computer
as someone and trying to fix a bug is not
allowed. It makes it too easy to look over someone elses code,
and allow (sometimes unintended) code-copying. Describing to
someone your problem and asking for advice on how to fix it is
okay, but you should do the actual debugging yourself.
- Stealing someone elses design. Discussing design with
someone else and sharing ideas and critiquing each others design is
okay if attributed. However, just taking someone
elses design without trying to design yourself is not allowed. It
is akin to taking someone elses outline for a research paper and
basing your paper on that.
- Asking for help on something you havent thought about
yourself. Always make every attempt to tackle a problem
yourself before asking another student or a TA. It will help you
to become a better programmer, as well as a better student. The best
way to learn is to try!
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.
When we confront a student with a case of suspected violation, an answer
of I didnt know that this is wrong is not likely to
find much sympathy.
We take the Honor Code very seriously in this course and we have no
tolerance for behavior that falls outside our boundaries for acceptable
Please do your part in maintaining a community where academic work is
done with a high standard of integrity!
Some parts of this document based on a similar collaboration policy for Browns CS courses.