University of Arizona, Department of Computer Science

CSc 453: Programming Project: General

Overview In the course of the semester, we will implement a compiler for a subset of C called C--. The project will consist of a series of programming assignments, each of which depends on all of the previous assignments. For this reason, it is crucial that you write your code in a way that makes it easy to debug and extend.

I will attempt to provide, to the best of my ability, a precise specification for each programming assignment. Programs are expected to meet these specifications exactly. Questions and clarifications should be settled beforehand. Programs that do not meet the stated specifications will be penalized heavily.

Time Allocation Each programming assignment will involve a time cycle of approximately three weeks: roughly two weeks will be given to complete the programming and turn in the code, and another 5-7 days (partly spanning the grading time) will be available for correcting any bugs before the next assignment is given out. Individual assignments may depart from this somewhat, depending on their level of difficulty.
Grading Policy Assignments are due at the time stated in the assignment handout. Late submissions are permitted, but will be assessed a late penalty of 10 points per day.

You may turn in multiple submissions for the same assignment: they will be graded separately, and you will be awarded the maximum of their scores (after adjusting for late penalties where appropriate). However, note that I will generally check the turned in assignments once a day, so a submission that comes soon after a previous one may overwrite the previous one. In this case, it will be possible to grade only the later submission.

In general, an assignment will be graded by comparing its output against the "expected output" on a number of different test inputs using the diff utility: if your output differs from the expected output, it will be considered to have failed that test (it is for this reason that strict adherence to the specification is important).

Correctness is always more important than efficiency.

Grading Procedure The size of the programs involved in the project makes it impractical to manually examine your source code to determine its correctness. Instead, we will use the following procedure:

  • You will develop and test your code using your own test cases. It is permissible for students to share test cases.

    I strongly recommend giving very careful thought to your test cases. In my experience it is very useful to have (1) a large number of small test cases, each of which tests one or a few language features; and (2) a shell script driver that runs your program on all your test cases and checks whether you got the output you expected.

  • I will make my test cases public after the submission deadline.

  • Your code will be grader on my test cases using a grading script. You will be awarded a preliminary score based on the number of test cases failed. This preliminary score will be sent to you by email.

  • If you were penalized more than once for the same problem, you will have the option of bringing this to my attention over the two weeks following notofication of your preliminary score. Specifically, you will need to provide me with:

    • a list of the specific problems in your code; and
    • for each problem, the test cases that failed as a result.

  • Based on this, I may adjust your preliminary score where appropriate, based on my assessment of the seriousness of the problems. However, any such adjustment will always be positive, i.e., you will not be penalized—but may be rewarded—for explaining the problems in your code.

Different assignments will be given different weights, based on their relative difficulty, and the weighted scores will be used to determine the final grade.

Style Some suggestions on programming style
Testing Hints on Testing and test case generation