ONAP uses Google Java Style with some modifications:

  • 4.2 Block indentation: +4 spaces

  • 4.4 Column limit: 120

IDE code formatter configurations can be found in the Google Style Guide repo.

References

From Setting Up Your Development Environment#ONAPEclipseJavaFormatter:

As per https://gerrit.onap.org/r/gitweb?p=aai/aai-common.git;a=blob_plain;f=onap-java-formatter.xml;hb=refs/heads/master, an ONAP Eclipse Java Formatter XML file has been merged and can be imported into Eclipse. Updates to the settings should be committed and merged back into the repository (e.g.  AAI-2198 - Getting issue details... STATUS ) . TBC: This should probably be in oparent for all to share.


17 Comments

  1. Catherine Lefevre

    Here are the other references:


  2. Tony Hansen

    For that matter, all of Google's language style guidelines can be found under https://google.github.io/styleguide/

  3. Gildas Lanilis

    This practice is recommended but not mandatory for Amsterdam release.

    Practice approved by TSC 2017-07-13 (topic #10). PDF Summary of materials presented.

  4. Chris Lott

    Since ONAP is recommending a modified Google style, it would be very useful if ONAP would publish the configuration files for popular IDEs like Eclipse, IntelliJ to implement that style.

    1. Mark Leonard

      The hyperlinks above can be used to find such configuration files. For example, here are the settings for (an unknown version of) Eclipse: https://raw.githubusercontent.com/google/styleguide/gh-pages/eclipse-java-google-style.xml. A developer could start with these settings and manually apply the modifications. I would be happy to share my current settings with you.

      I think it is a lot simpler to refer to the Google-maintained archive of the style guide and describe how ONAP deviates from this. If configuration files are published here then they will need to be maintained/synchronized. This process would be further complicated if multiple versions of multiple IDEs are supported.

  5. Jim Hahn

    I'd like to suggest that the column limit, for comments, be 90, as 120 is hard on the eyes, requiring much more visual scrolling back and forth.

    1. Mark Leonard

      I am interested to know how you are viewing the files. Is this a consequence of your particular settings (e.g. font style and size)?

      1. Jim Hahn

        Possibly, but doubt it.  If you open Eclipse and view a multi-line comment block where each lines goes out to 120 characters, you'll probably find that your eye has to bounce several times across the line to read it and it has to make a large jump to get from there back to the beginning of the next line.  Furthermore, with the large jump back, finding the correct "next line" is not always immediate.  It's just difficult to read that way.  Setting the limit to 90 characters seems to be a reasonable medium ground, not requiring so much eye motion to take it all in.

        1. Mark Leonard

          I am happy to support your proposal. There is evidence to back your assertion: https://en.wikipedia.org/wiki/Line_length

  6. Henrik Andersson

    When I build a project with Maven I get warnings when exceeding the column limit. But there are no Sonar warnings for this. The same goes for ordering of imports, I get warnings when using Maven but don't see anything in Sonar. Shouldn't Sonar also check these things?

  7. Mark Leonard

    The current standards do not stipulate exactly how a line that needs to be split should be indented. The Google Style Guide states the following:

    4.5.2 Indent continuation lines at least +4 spaces

    When line-wrapping, each line after the first (each continuation line) is indented at least +4 from the original line.

    When there are multiple continuation lines, indentation may be varied beyond +4 as desired.

    7.1.3 Block tags

    Any of the standard "block tags" that are used appear in the order @param, @return, @throws, @deprecated, and these four types never appear with an empty description. When a block tag doesn't fit on a single line, continuation lines are indented four (or more) spaces from the position of the @.

    Note that the Google Java Style uses 2 spaces for Block indentation. Therefore the line continuation uses at least two indent levels, in order to distinguish this from Block indentation.

    Some ONAP Java code is apparently indenting with 4 spaces (1 indent level) and some code indents to 8 spaces (which is my preference). Either would be valid according to the current definition of the standards.

    In summary, I believe that there is value in explicitly specifying the number of spaces to be used for indenting continuation lines.

  8. Kevin Smokowski

    Above links to an older git review for the file in aai common for the latest see https://gerrit.onap.org/r/gitweb?p=aai/aai-common.git;a=blob_plain;f=onap-java-formatter.xml;hb=refs/heads/master

    1. Keong Lim

      updated in wiki page.

      1. KAPIL SINGAL

        Google rleased version-13 now, I guess we should start using same: https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml

      2. KAPIL SINGAL

        The version or params in the xml file is quite old now, which are either not competible or missing new code style settings as per latest eclipse (2021-06)

        A competible copy can be found at: https://github.com/revelc/formatter-maven-plugin/blob/main/src/main/resources/formatter-maven-plugin/eclipse/java.xml

        which can further be altered as per ONAP's guideline

  9. Mark Leonard

    The last (non reverted) update to that XML file was in September 2017. See https://github.com/google/styleguide/pull/271. As far as I can tell the XML file itself is not versioned. The Code Formatter Profile version within the XML content relates to the version of Eclipse. You can see the details for version 13 here https://bugs.eclipse.org/bugs/show_bug.cgi?id=514019 

  10. Francis Toth

    It may be also useful to not limit these recommendations to formatting. Some well recognized practices should be also present in this document:

    I've opened an issue about this matter. Please comment on it if you are interested.