Project Correctness Checklist

posted by: Mr. Bergquist 14 November 2011 No Comment

You should by now have realized that I’m looking for some rather predictable things in your programs — style, good decomposition, reduced redundancy are the major ones. I’m still seeing some obvious things missing, though! Hopefully this checklist will keep you from making obvious mistakes.


You should exactly replicate the output shown in the assignment writeup. Why does it matter? I treat your assignments like industry products. If you were working for Microsoft and your team had agreed on a particular look and feel for a program you were writing, would it be ok for you to take some freedom and make up your own? Of course not, so it’s not ok here either. Use quickdiff to compare your output — copy desired output from the assignment prompt on the left side then put your output on the right side.


I hold you responsible for coding conventions we discuss in class. Here is our summary of conventions. This matters for working on collaborative projects and for your own sanity if you ever have to revisit your code (and makes grading easier).

Reducing Redundancy

If you find yourself using copy and paste, you should create a new method. If two pieces of code look similar but not exactly the same, could you use a single method with different parameter values passed in? As a rule of thumb, you should never have a group of 3 or more lines of code repeated more than once in your program. This will increase readability and maintainability of your code.

Procedural Decomposition

Figuring out how to decompose a program into methods is very challenging — there are clearly many ways to do it and it takes experience to figure out which ways are better. Recognizing good decomposition is a skill that transfers to many fields so it’s important to me that you get good at it. Here are some guiding ideas:

  1. Program logic and input/output should be separated. A method that calculates something shouldn’t also print the result because it may be desirable to use a different output mode at some later time.
  2. Each method should have a clear responsibility. You should be able to summarize what the method does in one short sentence without using “and.”  For example, in a complex project, one method should not do the prompting (scanning) for input values, calculation of new values AND printing out of the results – there should be a separate method for each; that way if you wanted to use the calculations elsewhere or perhaps get input from another source, you could reuse the separate methods easily.  If a method’s purpose is too narrow, it probably shouldn’t be its own method.  Here are three kinds of methods that should remain separate: a) Performs a calculation based on input parameter(s), returning the result  (i.e. Number of days in a Month) b) gathers user data and returns back the necessary result (i.e asks for day & month and returns the Absolute day) and c) prints out a block of text (i.e. an introduction) or the results at the end of a program based on input parameters, having no return (i.e. reporting the results of a game).
  3. Main should summarize the entire program. This is important so that someone can get a sense of the program at a glance. Main should direct program flow by receiving values from method calls and passing those on to other methods.
  4. No method chaining. You should avoid having methods that call methods that call methods in a long chain. That generally will result in a bad main and also makes it hard to find where program logic is. Instead, you should return to main and have main call the next method.
  5. No “do everything” method. When main gets big, it’s tempting to copy its content into a method and just call that from main. That makes main a bad summary of the program and violates the “clear responsibility” principle.  Keep methods to no more than 25 lines of code (not counting comments) unless there is a very good reason to go beyond this length, for example a long series of if/else’s that cover a large list of conditions.  It is advisable if you have such cases to review them with your instructor in advance of submitting the code.

Previous Project Score sheets:

Some of you are making the same mistakes on every assignment!  PLEASE REVIEW FEEDBACK FROM PREVIOUS ASSIGNMENTS.  This class constantly builds on what we have done in the past.  Those who don’t pay attention to history are doomed to repeat it, or something like that.  See Mr. Bergquist if you need previous copies of your score sheets, I only charge a quarter.

1 Star2 Stars3 Stars4 Stars5 Stars (7 votes, average: 4.86 out of 5)
Loading ... Loading ...

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>