Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!princeton!allegra!ulysses!gamma!pyuxww!rruxa!gwl From: gwl@rruxa.UUCP Newsgroups: comp.edu Subject: Cheating on Programming Assignments Message-ID: <248@rruxa.UUCP> Date: Mon, 30-Mar-87 11:49:22 EST Article-I.D.: rruxa.248 Posted: Mon Mar 30 11:49:22 1987 Date-Received: Wed, 1-Apr-87 05:45:02 EST Organization: Bell Communications Research, Piscataway, NJ Lines: 65 A general problem that I am sure is encountered in any course in which programming exercises are assigned is cheating on the part of students. Reading each and every program may not necessarily catch all forms of cheating. Certainly if a student copies the work of another and makes only superficial changes to the code one should be able to detect cheating. One of the oldest tricks in the book is to fake the output or results of the program to make it appear to work when in fact it does not. In the old days when punched cards were used, the program listing and the output results were normally found on adjacent output pages that were physically connected when output on a line printer. However, today I am confronted with PC labs where output and code listings are generated on laser printers on separate sheets of paper. It is quite easy for a student to insert phony output with the code and hand it in. This has made my job much more difficult in that I must not only ensure that the student is writing good programs, but that they are also handing in work that is correct. I can no longer depend upon the results that I am handed due to the fact that I can not be sure that they were created from the code I am inspecting. Don't get me wrong. I DO NOT just look at the results and see if the program works. I read programs. I also inspect the test data used to ensure that the program will indeed handle all possible inputs. However, due to the lack of confidence in the supporting output, I must inspect each and every program with a fine tooth comb to ensure they even work for the test data that is being used. I have thought of a possible aid in solving this problem and I would like some opinions from others to determine if this is an appropriate step to take on this matter. All of the programs that my students write on on IBM PC clones. It would be very simple to require them to not only hand in a program listing with supporting output, but to also require them to hand in the source on a floppy disk so that I may actually subject them to my own test cases. This may make it possible to judge programs based upon feeding them the identical test data and evaluating the results. It would still be necessary to read the programs and judge them on style, structure, readability, etc....., but at least I could reduce the effort to determine correctness and have a more objective basis on which to grade these programs. Does anyone have any problems with this approach? The only people who I see that would oppose such a process would be those who would take the easy way out and doctor the output rather than expend the extra energy and time to make the programs work properly. -- George W. Leach Bell Communications Research New Jersey Institute of Technology 444 Hoes Lane 4A-1129 Computer & Information Sciences Dept. Piscataway, New Jersey 08854 Newark, New Jersey 07102 (201) 699-8639 UUCP: ..!bcore!{indra | yogi | njitcis}!reggie ARPA: reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA From there to here, from here to there, funny things are everywhere Dr. Seuss "One fish two fish red fish blue fish"