It is difficult to know where to draw the line between educationally useful sharing of ideas and the educationally destructive copying of ideas. I will quote Roger D. Eastman of Loyola College (ironically this is copied), who draws the line rather well for programming assignments:
``I encourage you to help each other with programming assignments, but I also want you to understand where the help should stop. Don't take someone else's program to copy, or give yours for copying. If you want to show someone your program to ask about a syntax or run-time error, that's fine; if you want to brainstorm about what the assignment requires and how to approach it, that's fine; if you want to share your knowledge of [C++], that's fine; but letting someone copy your program line by line, in fact or spirit, is not fine.''
The line between sharing and copying is clear: when you start writing code, it is time to stop sharing ideas. But what about when you are stuck with a syntax error? In that case it is all right to ask someone about the syntax error, but that is as far as your sharing of information should go. To put it still another way, it is wrong to show someone else a copy of your program for ``reference.'' Conversely, it is equally wrong to look at someone else's program for ``reference.'' A completed program should have a single easily and uniquely identifiable author.
Debugging code presents an even greater challenge. Typically, students who have completed a programming assignment become obvious targets for programming help. While we applaud the desire of students to help one another in the educational process, don't go too far. Once you look at someone's else's code, you are in danger of improperly collaborating. It is okay to tell the other person what is wrong, but do not offer a correct coding sequence. In addition, do not incorporate any of the code you may have seen into your solution. Above all, do not assume that helping someone fix their code means making it look like yours!
The normal procedure in suspected cases of improper collaboration is to submit the incident and individuals to the University Committee on Discipline. These policies and procedures are clearly described in the Lehigh University Student Handbook. Often, when the discipline committee finds a student guilty of copying, the penalty is a grade of F in the course. Subsequent offenses can result in academic suspension and ultimately expulsion from the university.
Some scenarios are presented below as examples. These are meant to be general examples, but may not be inclusive of all possible situations.
/* subroutine doit() Code supplied as a class example by Professor J. Knowitall in CSC 123, Fall 1999 */
More obvious examples of improper collaboration, i.e., blatant cheating, include submitting someone else's source code after modifying it by
This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -no_navigation -split 1 cheating.
The translation was initiated by Stephen Corbesero on 2000-08-29