CISC181, 05F, Academic Honesty Policies

Summary of Academic Honesty Policies

• Don't submit someone else's work as your own
• Don't falsify results (e.g. editing a script file)
• Don't cheat on exams
• Don't help someone else to cheat
• Don't remain silent if you know cheating is taking place

Details

There have been some questions regarding what behaviors are considered legal and heplful, and what behaviors are considered academic dishonesty. See the official policy at the UD website: http://www.udel.edu/stuguide/05-06/code.html and then read this:

First: Do not let anyone look at your code. Do not look at someone else's code. That is sharing code, and it is not allowed. Included in this category are all the ways one can share code, such as making it possible for someone to view your code, sending your code via email, and many others.

Second: Penalties for academic dishonesty are typically the same for both the sharer and the sharee; that is, you are just as likely to get in trouble for letting someone see your code as they are for looking at it.

How can I be helpful to another student without violating this policy?

1. Remember it is the responsibility of the student to seek help early and often from the TAs and instructor; if someone is begging you for help at the last minute, that is not your problem. We can all be sympathetic, but don't use that as an excuse to cross the line and jeopardize your own record.
2. You may discuss algorithms in general. Remember when we wrote recipes on the board? You can discuss recipes like that, though you should be careful about writing them down, because they can start to look like a program, and then you would be sharing code. But it is fine to discuss things like "this has to happen before that can happen" (unless that is a specific question in the assignment).
3. You can discuss resources: "We had that problem in lab 3, so look at your lab 3 code"; "The book shows that on page 277"; "My TA told me to think of this problem as an eggplant, and now it is clear."
4. You can usually work together on problems UNRELATED to assignments. For example, it is ok to work together on programs in your textbook. This gets to be academic dishonesty if, as the project deadline approaches, you are searching for textbook problems that look like the code you are trying to write.
5. You can usually write small programs together. If a person is having trouble writing nested for loops, you can write a six line program together that has nested for loops. HOWEVER, writing a function with someone, when that function is part of a required assignment, is NOT ok. Also, it is NOT ok to write several small programs together, the sum of which looks a lot like the assignment or a chunk of the assignment.
6. If you have any questions about what is ok or not ok, you can always ask your TA or instructor and we will let you know.
7. If you are in doubt, Don't Do It.
8. If you are not in doubt, think about whether you should be - review the note above and try thinking like an instructor viewing the question from the outside.

Some specific points about Script files (program output)

In addition to everything mentioned above, the following are also considered academic dishonesty in CISC classes:

1. Submitting someone else's script file as if it were you own.
2. Providing your script file to another student without specific permission from the instructor.
3. Submitting something that is NOT a script file AS IF it were a script file (e.g. typing in results into emacs that "look like" the script file "would look").

   For purposes of Computer Science, this is equivalent to "falsifying results" in a science class, and is a MOST serious violation of academic honesty.

4. Editing a script file in any way with an intent to deceive.
5. Because intent can be difficult to establish, it is better to simply NEVER edit a script file for ANY reason, unless you have specific permission to do so.

1. Typos in script files

   Some students are tempted to edit a script file to "clean up" typos on the command line that result in error messages, or mistyped commands, where the backspace character makes the line look messy etc.

   DON'T FIX THIS BY EDITING THE SCRIPT FILE.

   TAs should be tolerant of minor typos in commands, as long as it is clear from the print out what is happening.

   If the typos get so bad that the script cannot be read, the TAs might get annoyed and take off points. In that case, you should just redo the script file; don't edit it.

2. Is editing a script file EVER permissable?

   An example of a rare instance where editing a script file MIGHT 1be permitted is a program that calculates the first 1,000,000 prime numbers and prints them out. It might be permissible in such a case to edit the script file to show only the first 10, and the last 10, and then insert in between a few blank lines and the message:

        [ several hundred thousand lines of similar output omitted ]
   

   There is no intent to deceive if you insert a message saying that the output was edited and why.

   However:

   1. Don't do this without specific permission.
   2. A better solution is to modify the program so that it skips the output for all values between x and y, and give it the values x = 11, y = 999990.
   There is almost always a way to rewrite the program or the test case to avoid the need to edit a script file.