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-2198Getting issue details... STATUS ) . TBC: This should probably be in oparent for all to share.
17 Comments
Catherine Lefevre
Here are the other references:
Tony Hansen
For that matter, all of Google's language style guidelines can be found under https://google.github.io/styleguide/
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.
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.
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.
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.
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)?
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.
Mark Leonard
I am happy to support your proposal. There is evidence to back your assertion: https://en.wikipedia.org/wiki/Line_length
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?
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:
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.
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
Keong Lim
updated in wiki page.
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
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
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
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.