Skip to end of metadata
Go to start of metadata

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.


From Setting Up Your Development Environment#ONAPEclipseJavaFormatter:

As per;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.


  1. Here are the other references:

  2. For that matter, all of Google's language style guidelines can be found under

  3. 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. 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. The hyperlinks above can be used to find such configuration files. For example, here are the settings for (an unknown version of) Eclipse: 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. 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. 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. 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. I am happy to support your proposal. There is evidence to back your assertion:

  6. 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. 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.

    1. updated in wiki page.

  8. The last (non reverted) update to that XML file was in September 2017. See 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 

  9. 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.