Checkstyle, PMD, findbugs contrast

When people talk about code rule engines. Everyone likes to stand in his place and say what he prefers, and reject other tools.

For instance, a PMD supporter could say:

"Checkstyle is a stupid tool consuming time to search for tab characters when PMD is a smart one," can do the job alone As a good soldier, Findbugs is very good for resource consumption and macker are ... uh, what is Macker? “

Time to breathe! There is in fact no need to take such position since those tools are not competing but are complementary and should D simultaneously as it's the case in Sonar. Each of them are mainly targeting a certain type of coding rules: conventions (Checkstyle), Bad practices (PMD) and potential bugs (FindBugs).

The Convention type covers naming, comments and format conventions. Here are a few examples:is there javadoc on public methods? is the project following Sun naming conventions? Is the code written with a consistent format?

The Convention type has often the reputation of being fairly useless as the rules are very simple. How to explain then which most open source projects provide a Checkstyle file in their development guide, when the same pro Jects generally throw out anything useless? It is true to say that the Convention rules does not have impact on stability, performance or reliability of the application. However, the Convention type is the glue this enables people to work together and to free up their creativity instead of Spending time and energy at understanding inconsistent code.

The bad practices type consists of known behaviors that almost systematically leads to diffic Ulties over time. Here are a few examples's bad practices:catching a exception without doing anything has dead code Too many Methods Direct use of implementations instead of interfaces implementing-Hashcode () method without the ' not equals ' (Obje CT object) method

PMD is a kind of angel this always looks over your shoulder to remind your bad practices, in the same way that your C Ommon sense reminds to iterate with your customer at developing a complete functionality and to answer questions M your coworkers.

The potential bugs type helps you detect what are not clearly visible in the code and understand W Hy sequences of code could leads to potential bugs. Here are a few examples of potential bugs:synchronization on Boolean could leads to deadlock may expose internal Tation by returning reference to Mutable object method uses the same code for two branches

Bugs are like human relations, it isn't always easy to understand the problem as there are the many to parameters int o account. Can is a good idea to sometimes to the analyst to resolve them:-). Findbugs is a kind the analyst for your source code!

What ' s about Macker? Whereas Checkstyle, PMD and Findbugs focus their attention in analyzing sources and applying rules, Macker takes a big Ste P back to identity architectural issues. Here are few examples of architectural rules:classes in the UI layer could not directly access the data object layer, or U SE classes in java.sql External systems could not access internal implementation-classes (suffixed with ' Impl ') one function Al module may access another only through its APIs only classes implementing interfaces in JAVAX.EJB, and certain framework Packages, may use the EJB APIs

Macker looks at your application in the same way a mans on the moon looks at Earth:hey guys, what are happening? Pacific Ocean is too close to European continent! Once you have a clear idea of the what your architecture should look like, can easily model it with Macker to keep your AR Chitecture consistent over time. With Macker your can define architectural conventions and identify architectural bad practices.