What makes Checkstyle, PMD, Findbugs and Macker complementary ?
There is often some misunderstanding when people talk about coding rules engines. Everyone tries to take position in favor of his preferred tool and does his best to explain what are the weaknesses of the other ones. 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 that can do the job alone as a good soldier, Findbugs is very good for resource consumption and Macker is … 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 be used simultaneously as it is the case in Sonar. Each of them is 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 that most open source projects provide a checkstyle file in their development guide, when the same projects generally throw out anything useless ? It is true to say that the convention rules do not have impact on stability, performance or reliability of an application. However, the convention type is the glue that 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 well known behaviors that almost systematically lead to difficulties over time. Here are a few examples of bad practices :
- Catching an exception without doing anything
- Having dead code
- Too many complex methods
- Direct use of implementations instead of interfaces
- Implementing the hashcode() method without the not equals(Object object) method
PMD is a kind of angel that always looks over your shoulder to remind you of bad practices, in the same way that your common sense reminds you to iterate with your customer when developing a complete functionality and to answer questions from your coworkers.
The potential bugs type helps you detect what is not clearly visible in the code and understand why sequences of code could lead to potential bugs. Here are a few examples of potential bugs :
- Synchronization on Boolean could lead to deadlock
- May expose internal representation by returning reference to mutable object
- Method uses the same code for two branches
Bugs are like human relations, it is not always easy to understand the problem as there are many parameters to take into account. Can be a good idea to sometimes to see an analyst to help resolve them :-). Findbugs is a kind of analyst for your source code !
What’s about Macker ? Whereas Checkstyle, PMD and Findbugs focus their attention on analyzing sources and applying rules, Macker takes a big step back to identity architectural issues. Here are few examples of architectural rules :
- Classes in the UI layer may not directly access the data object layer, or use classes in java.sql
- External systems may not access internal implementation classes (suffixed with ‘Impl’)
- One functional module may access another only through its API
- 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 man on the moon looks at earth : hey guys, what is happening ? Pacific ocean is too close to European continent ! Once you have a clear idea of what your architecture should look like, you can easily model it with Macker to keep your architecture consistent over time. With Macker you can define architectural conventions and identify architectural bad practices.
Macker is not yet available in Sonar but you now have an idea on where we are going !
Really interesting.
Unfortunately Macker does not evolve anymore for a while (last release 0.4.2 : November 2, 2003). It’s pity because it seems to be a nice tools (we tested it one-two years ago). Does it means that you will try to relaunch the community ?
In case you don’t know, it exists a maven 2 plugin for Macker (cf. http://mojo.codehaus.org/macker-maven-plugin/).
By Sanlaville on February 20, 2009 at 6:19 pm
Hi Remy, the first step will be to integrate Macker as a Sonar plugin (SONARPLUGINS-35) without big changes on source code. In a second time, it’s a bit tempting to imagine an open source library which would merge ckjm, jDepends and Macker features. Indeed all those tools share the same data extracted from the bytecode with the bcel library. Moreover the source code necessary to extract this data is not really complicated :-)
By Freddy Mallet on February 21, 2009 at 6:12 pm
Hi,
there is another great architecture review tool, which is up to date: http://classycle.sourceforge.net
Perhaps this also is a candidate?!
By the way: sonar is a really great tool. Fantastic work!!
By Ulrich Frank on March 14, 2009 at 10:28 pm
In fact there are 3 candidates with Macker, Architecture Rules and Classcycle. The question is to know which one we’re going to use to do our first implementation but in any case, our plugins architecture will allow anyone to plug a new engine.
Thanks for this link as I didn’t know classycle. Do you know if its community is still active ?
By Freddy Mallet on March 15, 2009 at 9:08 pm
Well, in 2006 support for Generics has been added to classycle and the latest bug fix release has been release on 2008-03-17. I took a look at the source forge project page. Only one developer left … could be a little more ;). But I think it is more supported then Macker. Makers latest release is from 2003-11-03.
It’s also very interesting to take a look at the activity statistics:
- http://sourceforge.net/project/stats/?group_id=55296&ugn=macker
- http://sourceforge.net/project/stats/?group_id=79058&ugn=classycle
The Classycle site has some activity whereas the macker site is almost dead.
Thanks for the hint for Architecture Rules. I didn’t know this tool. I only took a short look at its site. One very interesting thing is the jUnit support. The architectural check can be obtained in regression tests and that is very fine.
One question regarding to sonar: you wrote that is possible to plug in a new engine. Is this described anywhere? I’d like to try this :).
By Ulrich Frank on March 15, 2009 at 11:29 pm
The tutorial to help the community to write its own plugins is under construction in our Confluence space. Should be released in the next weeks.
By Freddy Mallet on March 20, 2009 at 4:08 pm
Hi,
first of all congrats with sonar, it’s awesome! I’m a flex dev and noticed this site http://www.catalysts.cc/blog/actionscript-code-dependency-metrics-mit-asycleactionscript-code-dependency-metrics-with-asycle/
Thus acycle can be used with actionscript too. Maybe this could help in deciding the right tool. I guess more languages support would be favourable to a tool that only supports one language. BTW i don’t have any knowlegde about the other tools (might support more languages too) but this just looked good and i thought you might want to know about it.
So this would be a great addition to sonar flex!
By Arnoud Bos on October 20, 2010 at 7:19 pm
Congratulations on a very sensible writeup on the different tools out there.
I would also add my support for the excellent http://classycle.sourceforge.net tool. It is also useful for detecting circular dependencies.
I would also mention that Checkstyle has the check ‘ImportControl’ (http://tinyurl.com/9jbxm) which can be used for ensuring that application layering rules are not violated, especially on large projects.
Disclaimer: I am the founder of the Checkstyle project.
By Oliver Burn on October 28, 2010 at 11:36 am
Short and clear description on the differnce between the 4 tools. thanks a lot.
By Prabhakaran on February 8, 2011 at 3:40 pm