Examples of Cheating (and Not)

The Student Conduct Code defines what qualifies as impermissible student behavior at UH in general. This includes what counts as academic dishonesty--specifically, cheating and plagiarism.

The following document explores 8 different scenarios that should help clarify exactly what counts as cheating in this course in particular. As with all moral behavior, there are often grey areas.

Scenario 1: Received code [Cheating]

"Your friend writes some code, which he gives to you. You then submit this code as your own."

Your "friend" may be someone you know in class, but it may also be someone who took the course previously or even just a resource you found on the Internet. Turning in someone else's work as your own is never acceptable in any class or endeavor. It is considered both plagiarism and copyright infringement. (And just changing a few variables names does not make it your code.)

Scenario 2: Copied code [Cheating]

"Your friend writes some code, which you then see and copy down. You then submit this manually copied code as your own."

Your "friend" may or may not know you are copying his code. Again, turning in someone else's work as your own is never acceptable in any class.

If you incorporate only part of another's work into your own, this might simply be "research". However, you must then cite where you took that part; if you do not, you are plagiarizing. The same standard applies to writing code--give credit to any sections of code you reuse. However, since you are supposed to be writing your own code for assignments, you generally will not have the option of reusing someone else's code in this class.

Scenario 3: Group code [Grey Area]

"You and your friend work together writing some code. Then you each submit this code as your own."

This can be a grey area because sometimes--even in this class--you may be specifically asked to work together as a group. In that case, this is obviously not cheating.

However, if you have been instructed to work individually, then this is considered cheating. (Hint: if you're working individually, then you better be in front of your own keyboard working on your own code.)

Scenario 4: Dictated code [Grey Area]

"Your friend tells you what to code to write. Following his instructions, you write the code and then submit it as your own."

This often starts out innocently enough--your friend is just trying to help you out by explaining how to do something. This is why this is a grey area. This is fine if your friend just helps you out with a couple lines.

However, if your friend ends up directing you through the whole program, then you are not an author of the code but simply a transcriber. In this case, you have not written your own code, and so you have cheated.

Scenario 5: Mirrored code [Grey Area]

"You and your friend are sitting next to each other, each working on your own code. However, throughout the process, you borrow sections from his code (and he may borrow from you)."

Again, this is a grey area because a little of this is okay. Examining and discussing code lets you learn new techniques from your peers.

However, this can become cheating if you do it too much. If the end result is the same as the Group code scenario (except you simultaneously produced two copies of the code), then you are not doing your own work.

Scenario 6: Discussed code [OK]

"You and your friend discuss how to solve the problem--such as how to break things down into functions, whether a loop might be required (and what kind), how many variables will be needed and of what type, etc. However, you write the code itself separately from each other."

Ideally, this is what you should be doing instead of Mirrored code--sharing and discussing ideas rather than specific code details.

When I was in college, my roommate and I had the same political science class. We sat on opposite sides of our dorm room, each working on our own version of a paper for the class. However, after every couple paragraphs we'd pause to discuss our thoughts, arguing until we agreed on the next point. Although we never even saw each other's papers, this constant discussion of ideas throughout the writing process was enough that the instructor asked us to work more independently in the future. So even this scenario is not without its perils. But in this class, your code will be sufficiently different if you are only discussing ideas, process, and algorithms, rather than syntactic details.

Scenario 7: Bug help [OK]

"You are writing your own code, but you get stuck with a strange bug. Your friend has a look and helps you track down the bug."

Although your friend is helping, he is not determining the direction of your code. In fact, this can be a valuable learning experience for your friend, since he must read and adapt to your code before being able to track down the bug.

Still, don't do this for every bug--you need to learn to debug your own code.

Scenario 8: Solo code [OK]

"You write your own code, debug it alone, and submit it."

When in doubt, this is always safe, forcing you to become a self-sufficient programmer.

Conclusion

The point of all these scenarios is that you need to do your own work. You don't need to completely avoid your peers or be afraid to ask them for help. Just be aware of the degree of help--are they teaching you how to do it on your own, or are they doing it for you?

Later on in your ICS career, exposure to other programming styles will provide important learning experiences. But at this level, it's still important you understand the basics and prove that you can use them on your own.