Programming Style Guidelines

Opening block comment

Every file should contain an opening block comment describing what it is.

Other Comments

Use additional comments to clarifly major sections of lengthy methods or otherwise tricky parts of the code. Make sure the comments actually provide additional information to the reader. With well chosen variable and method names, most lines do not require a comment. But a comment can introduce a block such as a loop, e.g.
//print the elements of the array
for (...) {...}

Variable Names

Your variable names should begin with a lowercase letter, and use uppercase to separate embedded words (as in someVariableName). The variable names must be descriptive English words. There are only a few exceptions to this and they will be discussed in class (e.g. i is an acceptable loop index if it is indeed an arbitrary index into an array). It is better to err on the side of long and descriptive (use "index" instead of "i", use "quarters" instead of "q").

Proper Indentation

You must use proper indentation. E.g.

if (test) {
 doSomethingHere();
}

or

if (test)
{
 doSomethingHere();
}

No Tabs

The source files you submit MUST NOT contain any tab characters. The problem with tab characters is that different editors set different tab stops. You can use the unix expand command to remove tabs before submitting your program. Most IDEs have aa setting that allows you to type tab but have it in fact insert the appropriate number of spaces.

No Long Lines

Limit your source lines to 120 characters. Keeping the lines within 120 characters makes it easy to view the source code from many different editors without worrying about unexpected line wrapping.

Block Comments on Methods

Every method should have a block comment that describes what it does including all parameters, any assumptions the method makes and any return value. 

No Magic Numbers

Your programs should not contain "magic numbers." A magic number is a literal constant (with the exception 0, +1, and -1) appearing anywhere in the source of a program except to initialize a symbolic constant (e.g. "static final int size = 5;" is ok, "for (i = 0; i < 5; i++) ..." is not (because of the 5 not because of the 0). If a numeric literal occurs only once, then creating a constant is not mandatory but still often helps with documentation.

Use if-else-if-else when called for

Do not use a series of if-statements when at most one of the conditions is expected to be true. Instead use if-else-if-else-if...

No "break"

Do not use break except in switch statements.

Proper use of boolean (Java programs Only)

Do not use an integer where a boolean is called for. E.g. don't use "while (hasMoreInput == 1)...", use "while (hasMoreInput) ...".

Do not test against true of false, just use the boolean expression itself instead. E.g use "while(hasMoreInput)" instead of while(hasMoreInput == true)".

No Loooong Methods

Except in the case of an if-else-if.. or switch statement with many cases, each of which is at most 2 or 3 lines long, break methods that are over 50 lines into smaller subparts. Ideally methods should be 25 lines or less.

Don't Miss Opportunities for Methods

Avoid repetitive sequences of lines that could/should be easily converted into a method.