Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »

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.

DSpace Java Style Guide (Adopted 2018, for DSpace 7.x and above)

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

  1. 4-space indents for Java, and 2-space indents for XML. NO TABS ALLOWED.

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

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

  3. Maximum length of lines is 120 characters (except for long URLs, packages or imports)

  4. No trailing spaces allowed (except in comments)
  5. Do not use wildcard imports (e.g. import java.util.*). Duplicated or unused imports are also not allowed.
  6. 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

  7. Tokens should be surrounded by whitespace, e.g. http://checkstyle.sourceforge.net/config_whitespace.html#WhitespaceAround

    // This is NOT valid. Whitespace around tokens is missing
String []={"one","two","three"}

// This is valid. Whitespace exists around all tokens
String [] = { "one", "two", "three" }

  8. Each line of code can only include one statement.  This also means each variable declaration must be on its own line, e.g.

    // This is NOT valid. Three variables are declared on one line
String first = "", second = "", third = "";

// This is valid. Each statement is on its own line
String first = "";
String second = "";
String third = "";

  9. No empty "catch" blocks in try/catch.  A "catch" block must minimally include a comment as to why the catch is empty, e.g. 

    try {
  // some code ..
} catch (Exception e) {
  // ignore, this exception is not important
}

  10. All "switch" statements must include a "defaut" clause.  Also, each clause in a switch must include a "break", "return", "throw" or "continue" (no fall throughs allowed), e.g.

    // This is NOT valid. Switch doesn't include a "default" and is missing a "break" in first "case"
switch (myVal) {
  case "one":
     // do something
  case "two":
     //do something else
     break;
}

// This is valid. Switch has all necessary breaks and includes a "default" clause
switch (myVal) {
  case "one":
     // do something
     break;
  case "two":
     //do something else
     break;
  default:
     // do nothing
     break;
}

  11. Any "utility" classes (a utility class is one that just includes static methods or variables) should have private constructors, e.g.

    // This is an example class of static constants
public class Constants {
   public static final String DEFAULT_ENCODING = "UTF-8";
   public static final String ANOTHER_CONSTANT = "Some value";

   // As this is a utility class, it MUST have a private, empty constructor
   private Constants() { }
}

  12. Each source file must contain the required DSpace 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/
 */


Old DSpace Java Style Guide (for versions 6.x and prior)

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:

  • Curly braces must be on new lines.
  • Source files must have a copy of the copyright Duraspace notice and BSD license at the top (see Licensing of Contributions below). Also take a look at Copyright and Licensing.
  • You must use 4-space tabulation.
  • 'else' should be on a new line. 'else if' stays on one line.
  • Users of the Eclipse IDE can have eclipse do the formatting automatically using this profile: - Dspace-eclipse-format.xml. See the Eclipse section below for details of how to apply this profile.

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.

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:

  • Longer lines (than both Google and Sun) at 120 characters
  • K&R style brackets/braces
  • 4-space indentation (same as our current guide, but different from Google)

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?

  • Initially, likely just the master branch, and perhaps just specific modules (e.g. "dspace-spring-rest") on the master branch.
    • Enabling on master branch only may complicate cherry-picking of code changes from other branches (as line numbers, spacing, etc may change when the code is updated to use the latest DSpace Style Guide)
    • However, if we implement this module-by-module (starting with "dspace-spring-rest", the new DSpace 7 REST API), this may temporarily minimize the cherry-pick conflicts while also ensuring any new code meets the new style guidelines.
  • Backporting to other branches (dspace-6_x, dspace-5_x, dspace-4_x) is yet to be determined.
    • Backporting might affect local checkouts/forks of these branches, as a large number of files will change at once. This has the potential to cause local merge conflicts to occur, if an institution has made Java code customizations.

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

Configure IDEA for bulk cleanup
  • Install checkstyle plugin: https://plugins.jetbrains.com/plugin/1065-checkstyle-idea
    • File →  Settings →  Plugins
    • Restart IDE
  • Configure it to use our custom checkstyle.xml
    • File →  Settings →  Checkstyle
    • Add a "Configuration File" (press the + in the table). Select our checkstyle.xml
    • Make it "Active"
    • Click Apply
  • Update IDEA's Code Style to obey the Checkstyle Rules (See also https://stackoverflow.com/a/35273850/3750035)
    • File → Settings → Editor → Code Style
    • Click the small gear icon next to "Scheme", Select "Import Scheme" → CheckStyle Configuration
    • Select our checkstyle.xml
    • Click OK
    • Click Apply
  • Update IDEA's Java code style to align with a few specific CheckStyle rules (which don't seem to be auto updated per previous step)
    • First, order import statements per our rules
      • File → Settings → Editor → Code Style → Java → Imports
      • In the "Import Layout" section, ensure  the settings are in this order
        • "import static all other imports"
        • <blank line>
        • "import java.*"
        • "import javax.*"
        • <blank line>
        • "import all other imports"
      • Once reordered, click OK
    • Then, update to auto-wrap lines at the right margin
      • File → Settings → Editor → Code Style → Java → Wrapping and Braces
      • CHECK "Ensure right margin is not exceeded"
      • Click OK
    • Then, OPTIONALLY, for better looking bulk reformatting, you may want to tweak which types of statements are set to "Wrap if long"  (NOTE: this is very opinion-based, so choose something that looks good for you, based on the examples given)
      • (NOTE: Without these settings, IDEA's bulk "Reformat Code" option sometimes will generate line breaks wherever the line ends, which can result in somewhat odd looking code. These settings cleanup some of the more odd line wrappings that may occur.)
      • File → Settings → Editor → Code Style → Java → Wrapping and Braces
      • Optionally, set all of the following to "Wrap if long":
        • Extends/implements list (also check "align when multiline")
        • Extends/implements keyword
        • Throws list
        • Throws keyword
        • Method declaration parameters (also check "align when multiline")
        • Method call arguments (also check "align when multiline")
        • Chained method calls (also check "align when multiline")
        • "for()" statement (also check "align when multiline")
        • "try-with-resources" (also check "align when multiline")
      • Click OK
  • Update IDEA's Javadoc settings to not insert "<p>" on blank Javadoc lines (as this will cause IDEA to change all our DSpace license headings improperly)
    • File → Settings → Editor → Code Style → Java → JavaDoc
    • UNCHECK "Generate <p> on empty lines"
    • Make sure "Keep empty lines" is checked
    • Click OK
Use IDEA to perform bulk cleanup
  • Now open up any Java source file. You'll see Checkstyle warnings appear (if any) in RED.
    • This highlighting is enabled via the checkstyle plugin.
  • Bulk Reformat (an entire module): You can also reformat code in bulk in IDEA: https://www.jetbrains.com/help/idea/editor-basics.html#reformat_rearrange_code
    • Right click on a single directory / module
    • Select "Reformat Code"
      • Check "Optimize imports"  (This will remove any import statements with an asterisk)
      • Leave "Rearrange entries" unchecked (This will rearrange methods/variables based on arrangement settings in IDEA. We don't need this)
      • Under "Filters" → Check "File Masks" and enter in "*.java, *.xml"  (As we'll only bulk reformat Java and XML files)
      • Click Run

  • Finally, run Checkstyle against the module. There likely will still be a few failures to fix manually.

    # mvn install  (Only necessary if checkstyle:check below complains about missing SNAPSHOT dependencies)
mvn -U checkstyle:check

  • Also double check license headers are still accurate. Sometimes these get "munged" during bulk reformat (as IDEA occasionally tries to merge nearby comments into one larger comment)

    mvn license:check
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.