Code Style

Consistent coding style makes code easier to maintain. When submitting pull requests containing new code or modifications to existing code, please try to stick to these guidelines. If ever in doubt about anything here or in the code, simply ask about it on the forums or IRC.

Not all files currently follow these guidelines. If you find yourself modifying one of these, it is more important to be consistent within the file than to be consistent with the rest of the project, e.g. don't mix different line endings within a file. This also ensures that your diffs clearly show only relevant changes.

TODO: It's always a mess to do it (makes blame and diff less useful across the update), but some cleanup may be needed for particularly bad files.

Line endings

• Use Unix-style line-endings, i.e. LF (\n) instead of CRLF(\r\n). More details can be found in the GitHub Help on Line Endings. Use the following command to correctly set the core.autocrlf option.

Mac/Linux

$ git config --global core.autocrlf input

Windows

$ git config --global core.autocrlf true

Indentation

• Indent blocks with tabs. Do not use spaces.
• Use the 1TBS style. Statements such as if, else, or while should include their opening brace on the same line. Always use braces, even for single-line conditional statements.

Good

if (condition) {		// Opening brace on same line as statement
	doSomething();
} else {			// else on same line as closing brace
	doSomethingElse();
}				// Final closing brace on a line by itself

Bad

if (condition)
{
	doSomething();
}

if (condition)
	doSomethingElse();

Worse

if (condition) doSomething();

Naming

• Stick to US English spellings, e.g. use color rather than colour, couleur, or カラー.
• Use the standard Java naming conventions.
  • Classes and Interfaces should be nouns in capitalized CamelCase, e.g. MojamComponent, TitleMenu
  • Methods should be verbs in camelCase with the first letter lowercase, e.g. run, scaleBitmap
  • Variables should also be in camelCase with the first letter lowercase, e.g. color, blitWidth
  • Constants should be in UPPERCASE, with words separated by underscores ('_'), e.g. SCALE, GAME_VERSION
• Try to avoid excessively shortening variable names. Don't use single letters except when their meaning is clear, e.g. i as an index in a for loop. Also common are x, y, w, and h, but use longer names when appropriate, e.g. xOffset instead of xx, x2, or other equally obscure transformations.

Comments

• Try to keep the width of comment blocks within 80 characters.
• Use multi-line /* */ comments for comments spanning multiple lines, rather than repeated single-line // comments.

Good

/*
 * An asterix also begins each
 * line in the comment block.
 */

Bad

// Don't use these for
// multi-line comments.

Line Length

• There is no hard limit on the length of lines containing only code, but try to split longer lines (over 120 characters) if possible.
• Do not leave spaces at the end of a line.
• TODO: Splitting conditional and arithmetic expressions
• TODO: Splitting a long function definition or call

Spacing

• TODO: Probably just for the truly pedantic, but include some examples of spacing around parameters in function calls, array indicies, and around statements.