All code in any code-base should look like a single person typed it, no matter how many people contributed.
Rick Waldron
The reason for having one style for all written code is, that it is easier to feel home for each member of the team and concentrate on the job.
Arguments over style are pointless. There should be a style guide, and you should follow it.
Rebecca Murphey. Principles of Writing Consistent, Idiomatic JavaScript
It is also the only way to auto-format it. Auto-formatting releases the burden of manually indenting and typing spaces at the right places. It also helps you to compare changes before committing code to your favourite SCM tool.
I prefer auto-formatting over manual formatting although there are deficiencies: you cannot indent a section of your code in a way that makes it more readable. If the formatter is missing a format feature, you have to live with less readable code. But the formatters catch up quickly and not having to worry about manually formatting code is more productive and fun in my way of writing code.
Auto-formatting is one thing. Having elements in an XML file, like Maven's pom.xml, there is more to it than aligning elements and attributes. The elements should be presented in the same order. Especially for larger POM files this makes it easier to find relevant parts as the properties or dependencies. Unfortunately for this goal, the XML schema provided by the Maven team is quite lax. Laxness has its advantages, especially for casual users or small teams, but with larger teams, where you want to make things easier by providing less freedom of choice (less freedom is in some areas a surprisingly good thing), a strict XML schema is more productive. Therefore we created, based on Maven's original XML schema a strict one. Now every element is expected at one place and this expectation can be tested automatically. On writing the stict POM XML schema we guided ourselves by the documented order as shown on the Maven web site.
If you are interested, you may download and use this strict POM from our maven-strict-pom project page.
Unfortunately the strict XML schema does only warn you on validating the POM file, if the ordering does not meet the strict XML schema. So you have to fix the announced validation error in the pom.xml manually.
What goes beyond the strict schema we offer in our project is what Maven SortPom Plugin does. It allows to sort your POM according to predefined rules.
The following configuration meet the constraints defined in our strict POM schema:
<plugin>
<groupId>com.google.code.sortpom</groupId>
<artifactId>maven-sortpom-plugin</artifactId>
<version>2.0.0</version>
<dependencies>
<dependency>
<groupId>de.smartics.config</groupId>
<artifactId>maven-strict-pom</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
<configuration>
<expandEmptyElements>false</expandEmptyElements>
<keepBlankLines>true</keepBlankLines>
<createBackupFile>true</createBackupFile>
<sortOrderFile>strict-pom.xml</sortOrderFile>
</configuration>
</plugin>
Unfortunately, if you are concerned with whitespace settings (like inside of description elements), the plugin does not preserve these spaces. But otherwise this fine plugin enables you to do auto formatting with your POM files!
