This Style guide is unofficial as of yet. Please see the Code Contribution Guidelines page for our old code style recommendations, which are still currently in effect.

Existing DSpace Java Style Guide

Per the Code Contribution Guidelines page (see "Coding Conventions" section), our existing style guide is listed as follows:

Your code needs to follow the Sun Java code conventions with the following minor modifications:

Your code should be well commented with Javadoc (including package and class overviews). All code contributions must come with Documentation. At a bare minimum, this should include Technical Documentation covering all configuration options and/or setup. See Documentation Contributions below for more details.


These existing style guidelines are based heavily on the Sun coding conventions (circa 1999) which are no longer maintained, but still available at http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Because the Sun Java style guide is no longer maintained, it will not be keeping up with current Java style best practices, features, etc.  We should consider whether we continue to base our style off this outdated guide, use a more modern guide, or develop our own guide.

Proposed DSpace Java Style Guide (work-in-progress - not yet approved)

If you would like to comment on this proposal, please add your thoughts to this Pull Request: https://github.com/DSpace/DSpace/pull/1895

Bolded rules are a change from our current Style Guide.

  1. 4-space indents for Java, and 2-space indents for XML. NO TABS ALLOWED.
    1.  Only exception is throws clause, which should be indented 8 spaces if on a new line

  2. K&R style braces required. Braces required on all blocks.

    if (code) {
  // code
} else {
  // code
}


  3. Do not use wildcard imports (e.g. import java.util.*). Duplicated or unused imports are also not allowed.
  4. Write Javadocs for public methods and classes. Keep it short and to the point.
    1. Javadoc @author tags are optional, but should refer to an individual's name or handle (e.g. GitHub username) when included

  5. Maximum length of lines is 120 characters.

  6. No trailing spaces allowed (except in comments)
  7. Tokens should be surrounded by whitespace, e.g. http://checkstyle.sourceforge.net/config_whitespace.html#WhitespaceAround

  8. Each source file must contain the required license header, e.g.

    /**
 * The contents of this file are subject to the license and copyright
 * detailed in the LICENSE and NOTICE files at the root of the source
 * tree and available online at
 *
 * http://www.dspace.org/license/
 */


Other Java Style Guides

Google Java Style Guide

The Google Java Style Guide is at https://google.github.io/styleguide/javaguide.html

Some of the primary differences of this style include:

Fedora Java Style Guide

The Fedora project has its own style guide at https://wiki.duraspace.org/display/FF/Code+Style+Guide

Some of the primary differences of this style include:

Resources

Checkstyle verification

While not yet implemented, we likely would want to implement some verification of code style guidelines via Checkstyle.  Checkstyle is widely used in the Java world, and supports both Google and Sun Java conventions, as well as custom configurations. 

Branches to enable Checkstyle on?

Which git branches would we want to enable Checkstyle on?

IDE Support

Most major IDEs include plugins that support Checkstyle configurations. The plugin usually let you import an existing "checkstyle.xml" configuration to configure your IDE to use and/or validate against that style. (Please note: we have not tested all these plugins as of yet, so mileage may vary until we test/verify the plugin is usable)

Fixing the codebase

Cleanup via IDEA