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 a thorough summary of conventions with great examples. This matters for working on collaborative projects and for your own sanity if you ever have to revisit your code.
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.
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:
- 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.
- Each method should have a clear responsibility. You should be able to summarize what the method does in one short sentence without using “and.” If a method’s purpose is vague, it should probably be restructured. If a method’s purpose is too narrow, it probably shouldn’t be its own method.
- 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.
- 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.
- 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.
Some of you are making the same mistakes on every assignment! To see an assignment’s feedback, visit the following address:
http://grade-it.garfieldcs.com/scoresheets/AP/10au/<your e-mail address>/<assignment>/
Where <your e-mail address> is the address you have been using when you turn in an assignment and <assignment> is in the form a# — a1 for the first assignment, a2 for the second, etc. If you have forgotten your password, ask me now!