Using google code formatter

Hi,

We have a pair of modules (possibly more down the line) and we were looking at how we could standardise the code formatting style using up to date Java code style standards and tools. We came across this style guide put together by Google.

They have a program which autoformats your code and there are actively maintained gradle or maven intregrations to hook everything up nicely. However, this departs from the current OpenMRS formatting rules which still uses OpenMRSFormatter.xml.

What are people’s thoughts on this topic? Should we maybe consider updating the formatting rules and tools used on OpenMRS core?

Key considerations:

  • Adopt a centrally maintained style guide instead of maintaining a custom set of rules which we are then responsible for maintaining
  • Might be more closely aligned to the broader international Java community
3 Likes

Shouldn’t it cause problems in OpenMRS old modules which have already followed OpenMRS formatter? If so, we need to re-format old modules as well.

huge refactoring would happen in both core and modules with such a change, one quick catch i have seen is 2 space indention in comparison to 4 space or tab in openmrs formatter etc. the advantage is a global format/style

Since the plugins autoformat the code, does any of this refactoring need to be done manually?

Yes, all actively maintained modules would then need to be updated to adopt this code standard as well.

Does this whole process not endanger The privacy and security of the system. Just asking out of curiosity.

code formatting or styling just improves code readability, imagine meeting

public static void main(String[] arg){System.out.println("go read further about code formatting/styling");}

vs

public static void main(String[] arg) {
  System.out.println("go read further about code formatting/styling");
}

which would you easily understand and contribute to?

1 Like

The bottom line is that there should always be a code formatter in place, whether it’s following Google rules or other valid ones. It’s only painful to deal with modules that still lack a code formatter, sending back contributors to go change their indentation… etc. This should just never happen.

@nthfloor I believe that the SDK tool that generates new modules should ensure that an appropriate code formatter is setup from scratch (at least for Java and JavaScript). Is this an SDK evolution that you could look into in regards to the formatter that you would like to advocate for?

the choice of plugin is done at:

@k.joseph good point. There are a number of modules that were generated with the older archetype and those did not define a parent POM.

Yes @mksd we’d like to advocate for upgrading the existing formatting plugin.

We’ve seen that the SDK tool automatically provisions any new module with the default formatting rules, which is good. But something our team noticed is that the existing plugin is quite old and no longer maintained. Last release of the module was 2013. So would be great to upgrade it to something actively maintained.