Contributing code

Submitting a GitHub pull request is the easiest way to contribute. We can never thank you enough for any contribution !

But to keep the source consistent, readable, diffable and easy to merge, we use a fairly rigid coding style, and all pull requests will be expected to conform to the style outlined here.

Code Formatter

To make it easier to format your code correctly, use the gwt-test-utils style formatter for Eclipse (Preferences | Java > Code Style > Formatter | Import...).

Class Structure and Member Sort Order

Java types should have the following member order:

1. Nested Types (mixing inner and static classes is okay)
2. Static Fields
3. Static Initializers
4. Static Methods
5. Instance Fields
6. Instance Initializers
7. Constructors
8. Instance Methods

Members that fall into the same category (e.g. static methods) should also be sorted in this order based on visibility:

1. public
2. protected
3. default
4. private

All methods should be sorted alphabetically. Sorting is also recommended for fields.

Using Eclipse, you can easily configure automatically sorting. Check the "sort members" feature in Preferences | Java > Editor > Save Actions | Additional save actions > Configure... > Sort members.

Than, just go to Preferences | Java > Appearance > Members Sort Order and configure it like that.

Unit Testing

Unit tests are very important, and we strongly encourage submissions that include them, adding new unit tests for new functionality or updating existing unit tests for bug fixes.

Tests for Java classes should be placed in a parallel source tree under src/test/java and the test class name should be suffixed with Test. For example:

src/main/java/com/googlecode/gwt/test/assertions/WidgetAssert.java
src/test/java/com/googlecode/gwt/test/assertions/WidgetAssertTest.java

The use of the parallel test tree has two major advantages:

You can do package scope testing (vs. a tests subpackage). There is a clear separation between production and test code making packaging easier. This reduces the number of build breaks and the amount of time spent updating build files.