Almost everybody agrees that having a consistent setup for compiler errors, warnings and the code formatter across all team members is crucial. However, many development projects still fail to achieve this. Surprisingly, the main reason for this seems to be that most developers are not aware that this can be easily enforced with Eclipse and use cumbersome »How to setup your workspace« descriptions in the developer wiki instead. In most cases these descriptions are outdated or generally ignored. As this is an issue that I have repeatedly discussed with our customers (and recently at the BITKOM Workshop in Frankfurt) I explain how enforcing a consistent setup for compiler errors, warnings and the code formatter works with Eclipse.

The Problem

The Eclipse Java compiler provides a multitude of sophisticated checks that greatly help to improve the quality of your code. However, to benefit from these checks, it must assured, that all developers use the same set of checks. Only then, rules like »the code may not have warnings before comitting it« can be applied. Obviously, consistency is also relevant for code formatter settings. Hence, for a smooth software development in every team larger than two, the following should be ensured:

• Everybody uses the exact same setup for compiler errors and warnings, i.e., when it is agreed that an unread local variable should create a yellow marker in Eclipse, it should do so for all developers.
• The same is true for Javadoc settings (in the case of Java): If it is agreed that Eclipse creates a warning for missing comments, it should do so for everybody.
• Equally important, the code formatter settings should be shared by everybody. This supports a consistent coding style and avoids surprises when code is merged.
• There should be way to update these settings consistently across the team. This is, e.g., necessary when it turns out that treating a missing comment as a compile error is a bit drastic after all or if things need to be updated for Java 8.
• Ideally, the settings should not only be consistent for all developers but also for all projects.

The Solution

Fortunately, Eclipse (with a little help from the version control system) provides a simple solution for all these requirements: project specific settings. To enable them, simply open the properties dialog of the project and enable them for errors/warnings or the code formatter settings. As the screenshot shows, the same thing also works for code templates and the code clean up settings.

After enabling project specific settings, a folder called “.settings” is created that contains more or less human readable configuration files. To see this folder in Eclipse, the filter for resources starting with a dot must be turned off in the package explorer.

To ensure that everybody shares the same settings, this folder simply needs to be committed to the version control system (VCS). When a developer freshly imports a project to his workspace, he automatically uses the correct settings. No further setup is required. If the settings change, they are updated across all machines via the version control system.

What can happen, though, is that a developer accidentally changes the settings and commits this version. While this rarely happens in practice, it should still be taken care of. One way to deal with this is to use the permission system of the VCS to prohibit committing this file. However, this is usually cumbersome to setup. Another way is to employ a simple step in the nightly build that checks if the settings files have changed. This works well for us.

The described setup leaves one open issue: consistency across projects. To enforce this, we used to employ Subversions “externals” mechanism, so that the “.settings” folders in each project where mere pointers to one central location. As we continuously had trouble with externals, we later replaced this with a simple build Job in Jenkins that checks for each project if the setting files differ from the master. If differences are found, the build fails. This ensures consistency across projects and, as described above, detects accidental changes to the settings files.

If you want to test this solution, you can download this example project and import it to your workspace.