Coding Guidelines

Wait, guidelines? What do you mean guidelines?

Yep. Guidelines. Everyone has their own style of coding, which is great and all, but not really the best when it comes to working on a large project with lots of different people. We try to follow the idiomatic Java guidelines as much as possible though, so there's not actually that much you have to worry about.

Comments

• The only time we want to see block comments is if you're documenting a class, method, or member variable.
• For anything else, use single line comments, even in a case like this:

// this is a really complicated section and it requires a very
// long explanation that will span multiple lines
int foo = bar;

• Note that there is a single space between the // and the first word of the comment
• Also note that the first word of the comment is not capitalized and there is no ending punctuation. This is intentional and should be mimicked by you.
• ALWAYS add your line comments above the code you are commenting, never on the same line like this:

int foo = bar; // this style is BAD

• There are many places throughout the code where this practice has not been followed and automatic code formatters have made things messy. If you see comments that look like this:

int foo = bar; // oh
               // no
               // bad
               // formatter!

feel free to fix them! Only fix comments if you're already working in a file and come across an error...don't search through the code to find and fix them.

Naming Conventions

• public static final fields should be placed at the top of the class as the first statements in the code, and named using all capitals and underscores to separate words, like this:

public static final int[] MY_FAVORITE_NUMBERS = { 1, 2, 3 };

• private static final fields should follow the same naming convention as their public counterparts, but should appear at the bottom of the class.
• Note that the order of qualifiers should always be static final
• All other member fields follow and be prefixed with m and use camelCase for the rest of their names, like this:

private boolean mIsFavoriteNumber;

• Overall, the ordering of member variables and methods within classes should follow the given outline, where each category is separated by a single blank line:

// public static final fields
public static final int[] MY_FAVORITE_NUMBERS = { 1, 2, 3 };
// ...

// Constructors
// ...

// public static methods
// ...

// public methods
// ...

// protected static methods
// ...

// protected methods
// ...

// private static methods
// ...

// private methods
// ...

// nested classes
// ...

// private static final fields
private static final boolean SHOULD_REFRESH;
// ...

// private static fields
private static int mFavoriteNumberIndex;
// ...

// private final fields
private final int mFavoriteNumberValue;
// ...

// protected fields
protected int mSecondFavoriteNumber;
// ...

// private fields
private boolean mHasFavoriteNumber
// ...

• If your combination of qualifiers doesn't appear in this outline, you probably shouldn't be using it (sorry folks, no public members here).
• Now again, legacy code does not follow these guidelines. Feel free to clean up anything in the file you are working with! You aren't required to clean up old code, but new code that does not follow these guidelines will not be merged.

Was that so bad?

We've tried to make this as simple as possible for you guys, while still keeping things nice and organized so chaos does not ensue. Follow these rules and your code will quickly be on it's way to being merged!