Do not use extra spaces around brackets. Use the second style, rather than the first.

if ( foo.equals( bar ) ) {     // don't do this

if (foo.equals(bar)) {

foo = barArray[ i ];     // don't do this

foo = barArray[i];

Auto-generated code in Eclipse often uses bad variable names such as arg0. Use more informative variable names. Use code like the second example here.

 public void readFields(DataInput arg0) throws IOException {    // don't do this
   foo = arg0.readUTF();                                       // don't do this

 public void readFields(DataInput di) throws IOException {
   foo = di.readUTF();

Keep lines less than 100 characters. You can configure your IDE to do this automatically.

Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3, argument4, argument5, argument6, argument7, argument8, argument9);  // don't do this

Bar bar = foo.veryLongMethodWithManyArguments(
 argument1, argument2, argument3,argument4, argument5, argument6, argument7, argument8, argument9);

Trailing spaces are a common problem. Be sure there is a line break after the end of your code, and avoid lines with nothing but whitespace. This makes diffs more meaningful. You can configure your IDE to help with this.

Bar bar = foo.getBar();     <--- imagine there is an extra space(s) after the semicolon.

This is also a very common feedback item. Don't forget Javadoc!

Javadoc warnings are checked during precommit. If the precommit tool gives you a '-1', please fix the javadoc issue. Your patch won't be committed if it adds such warnings.

Findbugs is used to detect common bugs pattern. It is checked during the precommit build by Apache's Jenkins. If errors are found, please fix them. You can run findbugs locally with mvn findbugs:findbugs, which will generate the findbugs files locally. Sometimes, you may have to write code smarter than findbugs. You can annotate your code to tell findbugs you know what you're doing, by annotating your class with the following annotation:

@edu.umd.cs.findbugs.annotations.SuppressWarnings(
value="HE_EQUALS_USE_HASHCODE",
justification="I know what I'm doing")

It is important to use the Apache-licensed version of the annotations.

Don't just leave the @param arguments the way your IDE generated them.:

  /**
   *
   * @param bar             <---- don't do this!!!!
   * @return                <---- or this!!!!
   */
  public Foo getFoo(Bar bar);

Either add something descriptive to the @param and @return lines, or just remove them. The preference is to add something descriptive and useful.

If you submit a patch for one thing, don't do auto-reformatting or unrelated reformatting of code on a completely different area of code.

Likewise, don't add unrelated cleanup or refactorings outside the scope of your Jira.

Make sure that you're clear about what you are testing in your unit tests and why.

Every class returned by RegionServers must implement the Writable interface. If you are creating a new class that needs to implement this interface, do not forget the default constructor.

New committers are encouraged to first read Apache's generic committer documentation:

HBase committers should, as often as possible, attempt to review patches submitted by others. Ideally every submitted patch will get reviewed by a committer within a few days. If a committer reviews a patch they have not authored, and believe it to be of sufficient quality, then they can commit the patch, otherwise the patch should be cancelled with a clear explanation for why it was rejected.

The list of submitted patches is in the HBase Review Queue, which is ordered by time of last modification. Committers should scan the list from top to bottom, looking for patches that they feel qualified to review and possibly commit.

For non-trivial changes, it is required to get another committer to review your own patches before commit. Use the Submit Patch button in JIRA, just like other contributors, and then wait for a +1 response from another committer before committing.

Patches which do not adhere to the guidelines in HowToContribute and to the code review checklist should be rejected. Committers should always be polite to contributors and try to instruct and encourage them to contribute better patches. If a committer wishes to improve an unacceptable patch, then it should first be rejected, and a new patch should be attached by the committer for review.

Committers commit patches to the Apache HBase GIT repository.

When you commit a patch, please:

<jira-id> <jira-title> (<contributor-name-if-not-commit-author>)

HBASE-12345 Fix All The Things (jane@example.com)