Impressions of the PMD Eclipse plugin

The other day there was one post about useful plugins for Eclipse from user gAmUssA , in which PMD was mentioned as well. I found this plugin interesting and I decided to try to set this little animal on my project ...

For a start, about a project is not quite a small java project with 2000+ code files. So to study this plug-in was that. He has been writing and writing for about 4 years and not less than 10 different programmers, both ours and foreign ones.
I will not go into the specifics of the project - it does not really matter now.
Well, in general, rushed ... He put it without any problems and unnecessary questions. I launched it and for 5-7 minutes he was engaged in in-depth analysis of all that nonsense that my colleagues and I had been writing for years. As a result, a result was issued in the Volations Overview View: a label with packages and classes in which “errors” were found. At the same time, in the Volations Outline View you could see the description of these “errors” and from there you could go to a specific line of code.
The plugin provides 5 priorities "errors":

1. Error High
2. Error
3. Warning High
4. Warning
5. Information

From the 3rd to the 5th, they are too insignificant to mention them and to a greater degree relate to the controversial kind of recommendations, like "A method argument can be declared final" (well, of course it can be declared final, but special there is no sense in this, as it seems to me), as well as unused imports.
Therefore, I immediately turn off the display of the “errors” of these priorities (the plug-in easily allows you to do this by clicking the corresponding button in the Volations Overview).
So, only the worst from the point of view of PMD errors remain.
Among them, I highlighted the most distribution in my code. Considering the volume of this code, I consider the resulting data to be a representative sample enough to speak about close patterns in other projects. :)

The most common errors were the following:

1. An abstract method
   It seems to me a controversial statement ... Well, I don’t need that heirs necessarily redefine this method. Why should I make it abstract?
2. System.out.print is used
   Then of course you can’t argue ... Someone debugged something and forgot to remove it. Shame on you And this is in the presence of a live logger.
3. Overridable method called during object construction
   This warning is very common for my code. And it also causes great doubts. It is clear why we should be afraid of this ... They say that we will not have time to initialize the object and we will pull something and everything will fall down. But PMD swears by this warning to any class method called from the constructor, be it a setter or something else (of course, if the method is not private). That is, from their point of view, the constructors should contain only direct initialization of internal parameters plus all the accompanying code. And if this code is a lot? And if it is used more than once? In general, if you strictly follow this rule, then it solidly complicates life.
4. Variable Naming Conventions
   It is clear to everyone what it is about and what it is wrong to call variables wrong. :) But there are situations when it is hard to do without it. In my case, most often this turned out to be the use of an underscore as a prefix or a suffix. But surely this should be avoided.
5. Avoid reassigning parameters
   (meaning the re-initialization of the input parameters of the method inside the method)
   From my point of view it is not beautiful. Indeed, it is better to use temporary local variables. Transparent code.
6. A class which only has private constructors should be final
   So why? What is in one thing that in another case the class is not inheritable. What is called, one does not interfere. Maybe I do not understand?
7. Do not use the short type
   Well, it's hard not to agree. It is used only to save memory, but in calculations it still converts to int and back. So I see the point of using only constants of this type.
8. Avoid instantiating Xxx objects ...
   Where Xxx is String, Integer, Long, Boolean ... They all have valueOf (), and the string doesn't need anything at all. By and large - the same eggs, only in profile. The only thing is, for numeric type wrappers, initialization via valueOf () according to their words “is more memory friendly”. Well, believe it.
9. Do not explicitly trigger a garbage collection
   I do not consider a direct call to the garbage collector in a good form, but still sometimes it is necessary.

findings

')
Well, in principle, a useful thing to catch small cockroaches from the code. But no more than. I can not say that the results of the plugin somehow surprised or upset me. It just became clear once again that we are working not without flaws and that there is something to strive for.
I also want to note that there is the possibility of writing your own rules for checking the code. I personally did not have time to try, but I think there is some field for imagination.

Thanks for attention. I hope this article was useful to someone.