T-Th 9:05
T-Th 11:15
in Olin 155

CS 1110: Introduction to Computing Using Python

Spring 2018

Academic Integrity

The Policy for Work on Assignments


In order to learn the material, we expect you to work in groups of one to two (as specified on an individual basis for each assignment) and complete the assignments by your own efforts. It's fine to get certain types of advice from other people (see Scenarios section below), but you should develop your own code. We do not want you to get "help" by seeing or hearing another student's solution, and we do not want you to do the assignment in a large team and then hand in several copies of the resulting code. We give you grades as a recognition you have completed the assignment in the way we asked.

So that students receive the maximum benefit of working on the assignments themselves, we also prohibit providing unauthorized aid to other students. While it may seem that showing someone your code is helping them, we view this as actually harmful to them, and providing unauthorized assistance is a violation of Cornell's Code of Academic Integrity (see I.B.2 of the Code).

Given the above, here are the course rules, where "you" means you and, if there is one, your one CMS-registered group partner,

(1) You must never look at, access or possess any portion of another group's code in any form.

(2) You must never show or share any portion of your code in any form to anyone except a member of the course staff.

(3) You must not ask for or use solutions from outside sources; for example, on online services like StackOverflow.

(4) You should specifically acknowledge by name all help you received, whether or not it was "legal" according to rules (1)-(3) above. This is also known as "citing your sources". See the sections below for how. Exception: you do not need to acknowledge the course staff (although we appreciate it if you do!).

Cornell Code of Academic Integrity

The following website explains the general Cornell academic integrity policy and procedures from the standpoint of the student, the instructor, and the members of an Academic Integrity Hearing Board.


Violations of the Cornell University Code of Academic Integrity occurring in Computer Science courses are taken seriously. While there are various ways the Code might be violated in CS 1110, plagiarism is far and away the most common transgression. Therefore, most of the rest of this page discusses how to avoid plagiarism.

Avoiding Plagiarism in Computer Science

One of the key things to understand about programming, and computer science in general, is that it is a writing-heavy discipline. When you create a computer program, you are writing a document, just like you write documents in an English class (or any class that involves essays). Therefore, many of the same rules that apply to writing essays also apply to computer programs, particularly regarding plagiarism.

Plagiarism is essentially a form of fraud. Every time you hand in a program in this course, you are representing it as the work of the stated authors (i.e., the members of the CMS group who submitted it, which should be the same as the people listed as the authors in the header of the submitted code) subject to any exceptions that are clearly stated in the submission itself. To avoid committing plagiarism, simply be sure always to accurately credit your sources. To do otherwise is to commit fraud by claiming credit for the ideas and efforts of others.

Acknowledging Sources

We do not require a formal bibliography like you would use for an essay. An acknowledgement can be a simple sentence such as

I wrote this function after looking at the following page on Stack Overflow: http://stackoverflow.com/questions/9189172/python-string-replace.

Just tell us the source, and how you it helped you with your code.

It is also very important where you place your acknowledgements. All acknowledgements are written using comments. There are three primary places to put acknowledgements, depending on how the source was used when writing your program. Depending on the contribution of the source, we may ask that you put your acknowledgements in more than one of these three places.

Header Comments

The header comments are the comments at the very top of an assignment file, where we ask you to put your net-ids and the date. These comments should contain the names of everyone who contributed to the submission. You can omit obvious contributions such as the course staff, but you should list everyone else.

If you talked to someone not in your CMS group and got an idea from them that became part of your solution, write this at the top of your submission. If someone other than the course staff gave you some debugging help, write this at the top of your submission. If you found a key solution to some sticky problem in a post on stackoverflow.com and incorporated that idea into your program, write this at the top of your submission.

Any and all contributions should be acknowledged in the header comments. These comments work as a summary for the rest of the assignment.


# a1.py
# Walker M. White (wmw2)
# September 1, 2013
# Some of my test cases were suggested by Lillian Lee (ljl2).

Function Specifications

If your source only helped you with a specific function, then you should include your acknowledgement inside the specification for that function. This is in addition to the acknowledgement in the header comments. You do not have to write anything new; you can write exactly the same thing in both the header comment and the function specification. It just makes it easier for us to find the acknowledgement if it is in both places.

   """Returns: true if shapes shape1 and shape2 overlap.

   Acknowledgement: Uses the Gilbert-Johnson-Keerthi algorithm.

   Precondition: shape1 and shape2 are both shape objects."""

If you copied an entire function from someone else, it is best that you use this type of comment so that we know exactly how much was copied (and how much was your own) when assigning you a grade.

Block Comments

Sometimes the source helps you with an even smaller amount of code, such as small part of a function, or a few test cases. If it is just a single line of code, you can write it using a # comment off to the side. If it is more than one line (but much less than a whole function), you might want to write the comments in a block. You write a comment with the acknowledgement at the start of the code, and another comment at the end.

As with function specification, these comments are in addition to the acknowledgement in the header comments. You do not have to write anything new; you can write exactly the same thing in both the header comment and the block comment. It just makes it easier for us to find the acknowledgement if it is in both places.

cornelltest.assert_equals(trim(' a'), 'a')
cornelltest.assert_equals(trim('b '), 'b')

# Lillian Lee (ljl2) suggested these additional test cases
cornelltest.assert_equals(trim(' '), '')
cornelltest.assert_equals(trim('a b'), 'a b')
# End Lillian's suggestions

Implications and Grading

Integrity is about being honest about the sources of the work you are handing in. Grades on course assignments, on the other hand, are about you showing us what you have learned.

If you turn in someone else's work for course credit, and forthrightly acknowledge you are doing so, you are not acting dishonestly and are not violating academic integrity, but that also does not show us you have learned anything. Thus, you may not receive grading credit, but you would not undergo academic integrity hearings.

If, on the other hand, you violate academic integrity by claiming someone else's work as yours or by giving unauthorized help, then, the academic integrity hearing process will be triggered, which can incur both grade penalties and storage of records by your College.


We do not want to discourage all forms of collaboration. You can certainly talk with students outside your group about an assignment. And sometimes students find themselves in a bit of a "grey area" where they are unsure of whether or not some form of collaboration will hurt their grade. For that reason, we present several scenarios that highlight the types of things that we see in this course.

Scenario 1 (Good Collaboration)

You work on your program with your partner, trade debugging strategies and maybe a test case or two with your friend Hakim. You also get a pointer for a neat way of writing up one line from your friend Claire. At the top of your submission you write

We discussed this project with Hakim and Claire, and we thank Hakim for suggesting some test cases (noted below). The idea of implementing compute_widget as a one-liner with map() is due to Claire.

In addition, you add detailed comments at the appropriate places. A few of the test cases are marked with a comment like "This test case is due to Hakim." You also repeat "The idea of implementing compute_widget as a one-liner with map() is due to Claire" in the specification for compute_widget.

In this scenario, you understand why the test cases are useful. You also understand how compute_widget works and typed in the implementation yourself after Claire explained it to you (without showing you her solution or working your solution out for you.) In this case we are happy. You learned a lot by doing the project and had fun helping each other out. There is no academic integrity proceeding, and no grade penalty.

Scenario 2 (The Group "Divorce")

You have found a partner and decided to work together on an assignment. However, somewhere along the way, it was not working out. Maybe you or your partner was not doing enough work. Or your partner found someone else that they would rather work with instead. You decide to go your own separate ways and submit separate assignments.

However, if you did any work together at all, there is guaranteed to be some similarity between your code. Therefore, you need to be very explicit in your code how you collaborated and when you stopped collaborating. At the top of your code, write something like

I was originally working with Mary. We worked together on the testing code. However, we stopped working together after the testing code, because I wanted to work with Joe instead. Joe and I worked on the widget class by ourselves.

Group divorces will be handled on a case-by-case basis. As long as you accurately cite the collaboration process and commit no fraud, there should be no academic integrity violation, although we may have to discuss precisely how to assign grading credit.

Detecting Integrity Violations

We detect academic integrity violations by looking for unusual code similarities. We say unusual, because some parts of the assignment are so straight-forward that everyone is likely to have the same code. But as the assignments get more and more complex, some parts are statistically unlikely to be the same between independent groups.

We detect these similarities with Moss, which was developed by a Cornell PhD. We give the Moss web-based software a directory containing all the submissions and another file containing the skeleton we gave you for that assignment. Moss returns a list of pairs of submissions, ranked by the percentage of similar lines and showing exactly where the similarities are. Changing variable names, spacing, or comments does not avoid detection.

If you are interested in how Moss works, you may take a look at it the Stanford website.

Final Thoughts

Yes, keeping track of who is due credit for ideas is work. But we want you to get in the habit of thinking seriously about these issues every time you write your name on your work. We do, and so does every reputable creative professional in any field. Learning to do this is part of what we want you to get from studying at Cornell.

If you find yourself in a situation where you are not sure what the right thing to do is, contact both profs and (if applicable) the head TA all in one email, explaining the situation (ideally before submitting the work). It is always better to ask when you are uncertain, and we are here to help you figure out what to do.

Course Material by: E. Andersen, A. Bracy, D. Gries, L. Lee, S. Marschner, C. Van Loan, W. White