CIS307[Spring2004]: GUIDELINES TO TA ON GRADING HOMEWORKS Students will create a directory for each homework containing all the files relevant to that homework. So for the fourth homework each student will have a lab4 directory. Then the student will submit a tar or tar-zipped file of that directory. Before tarring the directory the student will have cleaned the directory by removing object files, executables, and core dumps. Please have a uniform way of naming the students' homework submissions: use the class userid followed by "lab" and the number of the lab. For example c307105lab4 refers to the lab 4 of the student with account c307105. If the lab was tarred, the name will be c307105lab4.tar, and if it was tarred and zipped, the name will be c307105lab4.tar.gz. We are grading on a 0..20 scale. Grade the homeworks and create for each student a Grade.txt file with name of student, lab number, grade, then write comments on the program discussing errors and justifying the grade. Then send back to the student the Grade.txt file. To me you will send a tar file that includes all the submitted homeworks including your Grade.txt files. Usually I will assign the homeworks on a Tuesday to be returned on a Monday evening by 10pm. No late homework is accepted. Grading should be completed and returned to students and me by the Saturday evening preceding the due date. 1. Errors that are penalized lightly in the first lab, get penalized more in the second lab, and more in the third, .. 2. If there are important points that the student misses, talk about them. For instance be careful with locking, thread safety, the use of malloc and free. Also stress security, like problems in overflows (strcpy, sprintf, ..). Especially pay attention to the semantics of the program. Be sure that the student is doing what asked in the current homework. 3. Coding improprieties, such as including files that have executable code, should be noted. 4. If a student does not follow specs, that should be noted. In general changing specs without authorization should involve at least -5 5. Each file should contain the name of the file and the name of the student. 6. Students should create a makefile as they start to program not at end. This file should include the 'clear' option which should delete .o files, core dumps, executables, etc. before sending you the lab, they should run clean so that only the required files are sent. They have to send you the makefile and it must work. If not deduct at least 3 points. 7. The program should compile without warning when using the -Wall flag. If the program does not compile (does not generate .o file) you should not give a grade above 9. If the program compiles with warnings, deduct 1 point per warning. 8. If the program does not run with most of the features required, the maximum grade is 14. 9. Each function should have an explanation of what it does. Each global variable needs a comment that explains its role. Comments should not be added at the end. They should be added as the program is developed. 10. The program should be nicely indented. Indentation should be there at all times. It is not something to worry about at the end. Warn students that when they come to ask for help their programs should be formally well-formed: commented and intented. 11. If you see something particularly interesting (good or bad) in the code, put comment on it so that the student learns something extra. 12. Plagiarism/cheating is the negation of learning. Please forward immediately to me any homeworks you suspect to be plagiarized. After grading each homework, say lab 4, create a file commonErrorsLab4.html, with description of common errors that you have found when grading the homework. Discuss those errors in the lab.