Code Specifications

Good code is like a finely-crafted part of a machine. It is no more complex than it needs to be, it is interchangeable with other parts, and it is easy to maintain. The following standards come out of several years of teaching and grading. Following them religiously helps me to manage and test 20 different versions of the same program, and makes it much less likely that I will lose your file. (It also makes it easier for me to get your programs back to you sooner.) Any deviation from these standards can result in a lower grade.

General

I only need the source files and any necessary data files. Pre-compiled files (such as .class files) are useless to me, and will be ignored. Assignments for which you turn in only the .class files will be considered to be not turned in yet.
Please do not include an entire directory structure with your code. Simply turn in the source files, and any necessary supplementary files (all with your name attached). Zip files are fine, so long as the files don’t unzip into new directories.
For source files, include your name in a comment at the top of the file. This helps identify your code if it gets misplaced or renamed.
Also include any necessary instructions or special aspects of your code. This includes notes on extra credit, if you did any.
Take care that data files may be used from the same directory in which the program runs. Certain programming environments (e.g. Eclipse) separate source files and executable files into separate directories, which means that you must be careful when putting together your code to turn in—make sure it can work with data files and executable files (e.g. Java .class files) in the same directory.
Do not hard-code values. Even if your program is made to work with only a single data file, permanently setting parameters to particular values makes your code very difficult to maintain. Further, we will often test your programs on data sets that you’ve never seen, with different sizes.
Make your program robust to error conditions. If the user uses the program incorrectly, it should alert the user to the problem and give a jargon-free error message about how to fix the situation. The user should never see any exceptions or arcane messages (even if he or she is a complete idiot). If usage is particularly difficult, include notes in comments at the head of your main class.
Follow the specifications exactly. In computer science, we must be careful and we must be exact. Take care that you don’t accidentally misinterpret the instructions!

Java-Specific

For Java, please follow these specific points:

The name of your file should be the name of the class (or bigger class, if there are multiple ones) it contains.
Do not use packages!! Java’s implementation of packages makes grading small programs extremely difficult, because it means that programs must be run from a particular directory. Since the entire class’s files will all be compiled and run from one directory, the use of packages keeps the code from compiling.

Style

Of course, style will vary from language to language. However, some principles are constant:

Comment your code. Every function/method should have its own comment (though a group of related one-line functions may share a comment). In addition, there should be regular comments in the body of your code.
Use proper documentation comments. In Java, this means using Javadoc comments for every public method and class. In Python, this means defining the proper """ doc string within every public method and class. Other languages will have equivalents.
Name functions and variables properly. Function names should be verbs. Variable names should be nouns. Don’t use single-letter names unless the variable is an index, or there is a specific, special reason.
Skip lines. This will help your eyes pick out related blocks of code. Rule of thumb: comment line, 5 lines of code, skipped line. And skip a line between functions, excepting related one-line functions.
Maintain correct tabbing. Being careful about your program’s tabbing will help you find many bugs before they become problems.