(The information contained herein was copied and slightly edited, with permission from Ed Kay's Improper Collaboration Policy.)

In grappling with the course work, the sharing of ideas is educationally useful. The copying of ideas is destructive, fraudulent, and unacceptable.

YOU ARE STRICTLY FORBIDDEN TO COPY SOMEONE ELSE'S HOMEWORK OR PROGRAMMING ASSIGNMENTS, WHOLE OR IN PART AND SUBMIT THOSE ASSIGNMENTS IN YOUR NAME. YOU ARE STRICTLY FORBIDDEN TO MAKE TRIVIAL OR MECHANICAL CHANGES TO SOMEONE ELSE'S ASSIGNMENT SOLUTION AND SUBMIT THE TRANSFORMED VERSION IN YOUR NAME.

[W]hen 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 alright 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!

========================================================================

Example Scenarios

Some scenarios are presented below as examples. These are meant to be general examples, but may not be inclusive of all possible situations.

A group of students sit down for an hour to discuss how they each plan to attack the programming assignment. As long as specific code sequences and/or flow charts are not exchanged, this is acceptable collaboration.

Two (or more) students each complete a programming assignment. When it is done, they share their source files, and each student imports the best code and ideas from the other file. This results in essentially the same program being submitted by both the students. This is improper collaboration. Submit your own work.

Your friend tells you that he or she is having problems getting a particular method (function) to work and asks to see your version of just that method (function.) Even though this one method (function) may only a be a small fraction of the entire assignment, this is still improper collaboration since it is code sharing.

You find a discarded printout, a USB flash drive, or a file left on the hard drive or network in a computer lab and decide to use some of the code on it. This is improper collaboration. Even if the source of the code is anonymous, it is still tainted.

The instructor provides sample code available to the class as part of the regular lectures or perhaps via a web page. Unless there were explicit instructions not to use the code, it is acceptable to include that as part of your solution. However, you should always give proper attribution to the original author.

/* subroutine doit()
   Code supplied as a class example
   by Professor J. Knowitall
   in CS 106, Fall 2006 */

More obvious examples of improper collaboration, i.e., blatant cheating, include submitting someone else's source code after modifying it by

    Adding, changing, and/or removing comments.

    Changing the names of variables, constants, subroutines, and/or methods (functions.)

    Rearranging the order of the declarations, subroutines, and/or methods (functions.)

    Applying any combination of the above and/or other simple transformations.