A little problem which bugged me while searching the solution for [1] was that I had to change my checkstyle.xml and checkstyle-suppression.xml for several times. Unfortunately Eclipse-CS never noticed these modifications. So I restarted Eclipse every time to make the changes apply.

Then I stumbled by chance on an entry in Eclipse-CS’s bug tracker [2]:

“Alternatively to touching the Checkstyle configuration file you can clear the plugin’s caches by clicking the little yellow refresh button on the Checkstyle preferences page.”

And hey—after putting on my glasses and lowering the nose-screen-distance to “way to near”—there it was: a little yellow button on the preference page!

Have you ever turned a variable to a constant and—following the Java Code Conventions—also changed it’s name to upper-case? Sure, “ALT + SHIFT + R” does a good job but what if you have plenty of such adjustments to do?

There’s help out there—and because I always forget the following command I want to dedicate a post to one of my favorite Eclipse-shortcut:

"Strg + Shift + X"

Just mark the text you want in upper case and use this combination. By the way – the little brother of “Strg + Shift + X” is “Strg+Shft+Y” (to lower case).

Appendix: There’s a nice Eclipse-plugin available which shows you (very insistently) the usable shortcut of an action when triggering it by mouse: mousefeed [1]. Although it seems that this plugin isn’t actively developed anymore it’s worth a try.

Reference

Code Quality

We all agree—code quality is an important component of the development process. And we all agree—less times is spent for code quality than it should be. According to [1] code has to be written with an eye on readability which influences the costs in development process directly. Kent argues, that the easier your code can be understood by another developer, the faster he or she could be productive in bug fixing, extending or refactoring. And: the easier your code can be understood, the less new bugs are implemented.

There are some great tools out there, which could help to improve code quality, like Checkstyle [2], Findbugs [3] and PMD [4]. Checkstyle is a static code analysis tool which—unlike e.g. FindBugs—works on the source code directly. You can use some pregiven rule sets or define your own ones, you are able to change the rules themselves (e.g. adopt thresholds) and you are able to use them in Eclipse via the plugin Eclipse-CS [5] and in Maven (using the Maven Checkstyle Plugin [6]).

The problem

Now let us assume, that you are working in a software project with more than just you as a developer and you are using Checkstyle. It’s obvious that the rule set should be shared. And if you are using a suppression filter, Eclipse and Maven—you’re in trouble.

So let me summarize the boundary values quickly:

You are working with Eclipse and Eclipse-CS

You are using Maven in your buildsystem

You have your Checkstyle rules in a file “checkstyle.xml” which lies inside your project (here in the folder ‘checks’)

And configuring Eclipse for using the suppressions could be done in the Checkstlyle-Plugin directly (e.g. select “Window” → “Preferences” → “Checkstyle” in your IDE) or in the checkstyle.xml. Here you simpy add:

Note that the place holder “${config_loc}” is a build-in variable of Eclipse-CS and will point to the same directory where the checkstyle.xml lies. So for Eclipse that’s all—the suppression file will be used as soon as you do a new scan with Checkstyle. But if you call ‘mvn checkstyle:checkstyle’ (assuming you have added the checkstyle-plugin to your pom.xml like above) this will fail due to the fact that Maven doesn’t know ${config_loc}.

The solution

But there’s a way to let Maven know—and that’s also the solution of the given problem. Add the SuppressionFilter to the checkstyle.xml as shown above. Then add to your pom.xml:

The point is you are using a property file, declared by propertyLocation. This file (here checkstyle_maven.properties) lets Maven bind the variable ${config_loc} to the local directory ‘checks’ in which our checkstyle-suppressions.xml lies. The content of checkstyle_maven.properties is simply one single line:

config_loc=checks

Rerun Maven and a Checkstyle scan in Eclipse—now you are using the same rule set and the same suppressions.

About this blog

The intention of this blog is to give clues and solutions to problems I struggle with in my every day work. As not everything is worth to write about it and I also don't want to post stuff which could be found on
every corner of the internet this blog is updated continuously but not regularly.

If this blog helped you in some way or you want to share your point of view to
a given topic—feel free to do so. I appreciate every comment and try to answer
as fast as my spare time allows me to do so.