CISC103, 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
This section originally written by Terry Harvey.
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?
-
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.
- 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).
- 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."
- 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.
- 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.
- 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.
- If you are in doubt, Don't Do It.
- 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)
This section originally written by Phill Conrad
In addition to everything mentioned above, the following are also considered academic dishonesty in CISC classes:
- Submitting someone else's script file as if it were you own.
- Providing your script file to another student without specific permission
from the instructor.
- 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.
- Editing a script file in any way with an intent to deceive.
- 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.
Some additional points:
- 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.
- 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:
- Don't do this without specific permission.
- 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.
Phillip T Conrad
Last modified: Wed Jan 26 16:06:24 EST 2005