Using google code formatter

code-formatting
Tags: #<Tag:0x00007f23de7fa220>

(Nathan Floor) #1

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

(Jude Niroshan) #2

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.


(Kaweesi Joseph) #3

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


(Nathan Floor) #4

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.


(Noah Lufafa) #5

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


(Kaweesi Joseph) #6

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?


(Dimitri R) #7

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?


(Kaweesi Joseph) #8

the choice of plugin is done at:


(Dimitri R) #9

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