当人们谈及代码规则引擎时。每个人都喜欢站在自己的位置上说自己较为喜欢的工具，而排斥其他的工具。
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.