Hi There!

I'm Dan Schlegel, an Assistant Professor in the Computer Science Department at SUNY Oswego

CSC241 Assignment Grading Criteria

Assignments will be graded according to the following general criteria:

  • The program compiles and executes.
  • The program works as it should. This means that the program runs correctly, addressing all requirements of the assignment.
  • The general design of the program is clear and reasonable. No pieces of bad code (see below).

Each assignment is worth 100 points. Partial credit will be given for solutions that do not completely meet the above criteria.

Any program submitted containing compile-time errors (i.e., does not compile) or producing garbage output (multiple copies of the same line, nonsense data, etc.) will receive an automatic grade of zero. In other words, a) do not waste my time with poor attempts at partial credit and b) remember to always remove/comment your debugging code before submission.

Bad code will be penalized more and more heavily as we get towards the end of the semester, because you will be expected to be better coders the further we progress. In general, I define bad code as any piece of code that increases program complexity without having an obvious advantage. There will be many examples of both good and bad code provided in class. An example of bad code is the following block:

The good news: I do not have styling, indentation, or other appearance requirements. A program should rather work than look good, and you are overwhelmed enough as it is to think about both correctness and appearance.

At times I may question you about your submission (especially during live demos). If you are unable to explain satisfactorily the solution (what it does, how it does it, why it was designed that way, etc.), a substantial penalty will be imposed.


Students often wonder why a seemingly small error can cause a relatively large grade deduction. The reason is that software that does not work properly even in the smallest detail — not in these assignments, of course, but in the “real world” — can be costly or even dangerous to its users. Most employers of software professionals therefore have high standards for quality. I want you to get used to this: to understand that “almost right” isn’t good enough for most employers, and that as a professional it shouldn’t be good enough for you even if it were good enough for your employer. Therefore, an error that prevents your program from working (especially from compiling properly so it can run at all) can result in a significant grade deduction, even if the error is as small as an omitted semi-colon.


Adapted (and borrowing heavily) from Alex Pantaleev’s CSC241 Grading Criteria