Here is a big list of what I look at in trying to assess the quality of programs. These issues that are addressed here are at a moderately low level.
If there's one idea that could serve as a guide to good programming, it's
Cost or fun. Most of the cost of software, maybe 80% on average, is in the maintenance phase: fixing bugs, adding enhancements, adapting it to new systems, etc. That would be a good enough reason to aim for maintainability, but that's not really why I'm saying it. The same things that make software maintainable also make it easier and more pleasant to work on in the first place. Sometimes it takes a few extra key strokes or an extra moment of thought, but those are usually quickly repaid.
Breaking it down. We can make a top-down dissection of what makes for maintainability. Three topics that cover a lot of the maintainability territory are:
Sun's guidelines. Perhaps the most common coding guidelines are Sun's Code Conventions for the Java Programming Language, which can be read online of downloaded in several forms from java.sun.com/docs/codeconv/. My guidelines are basically theirs with a few changes.
static final), you should rarely have any static variables.
privatein almost call cases.
I'm flexible about the exact format, but this information should be there.
fishCount = fishCount + 1; // Increase fishCount by one.
int averageRain, n, currentVal, max;
Might better be written as follows
int averageRain; // Average rainfall over all time periods. int n; // Number of time periods. int currentVal; // Amount of rain in the current time period. int max; // Maximum rain in any time period.
Additions will be made as more programming concepts are covered.
Naturally a program must run and produce correct output. Unless there are serious problems, the quality of the user interface will not be important in the beginning courses.
Generally no credit will be given for a program that doesn't even compile.
Altho real world programs must handle problem cases, such as illegal input, students may ignore problem cases unless specifically required to do so. The more advanced the course, the more emphasis will be put on handling errors.
But if you do check for errors, observe the following.
If a program is useful, the users will want enhancements, bug fixes, etc. It's also necessary to update programs regularly because the computing environment continuously changes.
Someone has to change them, and surprisingly often, it isn't the original programmer. Therefore, one of the most important characteristics of real programs is that they must be readable and have a style that allows changes. Grading will emphasize readability, programming style, and correctness.
Conventions may not always match exactly how you think, but they have a big payoff in the long run.
I once worked with a programmer, RH, who had "unusual" style beliefs. He firmly held that the first clause in an if-else statement should be performed if the expression was false, not true!!! So, unknown to others, he made a private copy of the compiler and changed the code generation for if so it worked his way. Yes, every if statement in his modules worked the opposite of the way everyone else expected, even tho it looked like "regular" code. Unfortunately, he was a very productive coder. Epilog: He was fired when this was eventually discovered.