Gora Coding Style

This page provides a comprehensive account of the coding style(s) adhered to within the Gora project.

Introduction to Gora Coding Style

Most of the styling in Gora comes from the Hadoop/lucece world, but there is no strict enforcement to do this. It is also very similar to the sun spec except 2-spaces for tabs.

Please do:

• try to adhere to the coding style of files you edit;
• comment code whose function or rationale is not obvious;
• update documentation (e.g., package.html files, this wiki, etc.)
• try to provide a unit test that shows a bug was indeed fixed or the new functionality truly works

Please do not:

• reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits.
• comment out code that is now obsolete: just remove it.
• insert comments around each change, marking the change: folks can use subversion to figure out what's changed and by whom.
• make things public which are not required by end users.
• Combine multiple issues into a single patch, especially if they are unrelated or only loosely related. This is true even if the changes affect the same files. In some rare cases it is warranted, but for the most part it makes it harder for committers to evaluate the patch.