1. How Assignments are Graded

Grading is performed on the CS Dept's Linux servers. You may do your development work on the CS Dept's PCs, or on other machines more convenient to you. It's a good idea, though, before you submit your work, to upload your code to the CS Unix network and check to be sure that it still works after doing so. Even with Java's reputation for portability, this is not something you should take for granted!

The Grading Criteria for Programming Assignments 

  1. Satisfy the stipulations and limitations of the assignment.

    Some assignments may have certain stipulations, intended to fosus your work on particular topics or skills or sometimes just to make grading possible. You may be limited in what files you can change, what data structures you can use, etc.

    The point of any assignment is to practice and demonstrate your ability with certain skills and technqiues that we have covered in class. You might be able to get that program running in some completely different manner, maybe rewriting the whole thing from scratch. It might even be easier for you to do it that way. That doesn't matter. If you have not employed the stipulated techniques, your submission will be disqualified.

  2. Produce the correct output.

    The primary scoring criteria for programming projects is the percentage of the test cases on which your code produces correct output.

    While it's common in beginning programming classes to write interactive code that prompts for inputs and accepts them from the keyboard, few programs these days work that way. Most truly interactive programs will work through a graphic user interface. And we will do those late in the semester. But there are still many programs that work through simple text input/output interfaces. These programs typically read and write to files or possibly directly to other programs. Consequently, the I/O formats of these programs are crucial and must be followed very precisely.

The Anti-Grading Criteria for Programming Assignments These are things that you will not get points for in the grading of programming assignments:

  1. The code is "almost correct" or "looks similar to" a correct solution.

    Sorry, but almost everyone who submits buggy code thinks that their code is "almost correct", that it "looks like" code that "should work". It's a well-known truism in our field that most software projects are 80% complete for 90% of their development time. It's very easy to get code to a point where it looks like somethgn that should be correct and yet fails every test case submitted to it. The real effort in programming, and what you are rewarded for in the grading, is for getting past that point to something that actually passes one or more tests.

    This does not mean, as some folks complain, that I don't give partial credit on programmign assignments. Soem credit is awarded for code that compiles. More importantly, I generally have multiple test cases, and you will get crecit for those that you pass, even if you fail some others.

  2. Time spent on the assignment

    "I spent so many hours on this assignment." That's gratifying, but do you think that your classmates did not? Or, if someone managed to produce correct output while spending only half the time that you did, do you think that I should take points away from them for having done it more efficiently than you?

    Telling me how much time you spent on an assignment may earn you sympathy. And in some cases I may want to talk with you about whether you are using your time in a smart way. I may be able to suggest more efficient ways for you to approach your coding, testing, and debugging. But it does not demonstrate your mastery of whatever techqniques the assignment is trying to showcase.

The Auto-Grader Most programs in this course will be graded automatically. You will submit your assignments electronically. Within a limited amount of time (typically 15-30 minutes, but this may vary depending upon how many other people are submitting) your code will be compiled. If it compiles successfully, it will be run on the instructor's test data and scored on how well it performs. The results of the compilation and testing will be emailed to you (at your CS email account) and will be available on the website.

The point of the auto-grader is to provide you quick feedback. In many cases, you may be able to use that feedback to fix things before the final due date of the assignment. If I graded in the "traditional" manner (you turn things in and I grade them after the due date), you would not get that opportunity. That can be very frustrating (to me as well as to the students) when students make "silly" mistakes such as submitting the wrong file, writing code that takes its input from the wrong source, writing output in an incorrect format, etc.

Some people complain that the auto-grader is too picky or too strict. That's a bit misguided. The auto-grader only runs the tests that I would have run if I were executing your program "manually". (Now, if you want to complain that I am too picky, that's another matter entirely.)

Multiple Submissions If there is time before the due date, programs may be resubmitted without penalty at most twice (after the first submission, for a maximum of three total submissions). A few programming assignments may not permit re-submissions, in which case that will be stated explicitly as part of the assignment description. Non-programming assignments, in general, cannot be resubmitted.

The reason for allowing resubmissions is to give you a chance to recover from "silly mistakes" as described earlier or from fundamental misunderstandings about what the program is supposed to be doing. It is not intended to allow you to keep chasing points by passing one more test each time. You are expected to test your own code before submitting, and, if you have done that, you should not actually be surprised by the percentage of my tests that you pass or fail. Now, if you did not make a silly mistake and have time left before the due date and can incrementally improve your percentage of tests passed, I'm not going to complain if you use the allowed resubmissions for that purpose. But I'm also not going to be sympathetic to requests for "just one more submission" in order for you to increase your percentage of tests passed.

Appeals Instructors are fallible too, and sometimes we will have a bad test. If you discover a bad test when you review the assignment solution, you can ask to have it re-scored.

If you have done multiple submissions and actually made your code score lower on your final submission than it had on an earlier one, you may ask that your score be rolled back to the higher score. You have to ask, though. I generally don't notice when this has happened unless you tell me.


In the Forum:

(no threads at this time)