In my previous post, It’s time to create a custom checker…, we looked at the considerations involved in deciding which checker to create–AST or path?
In this post, we’re going to use a custom checker to enforce an internal coding standard that extends the default set of checkers in our source code analysis tool.
To do this, I’ve called upon Steve Howard, our head of Partner Support in Europe, to get us started with an AST checker to accomplish our goal.
Steve has coached many customers through the checker creation process. In his experience, the appeal of custom checkers lies in their ability to enforce naming conventions and code constructions across organizations.
The standard we want to enforce is the use of a compound statement block rather than single statements as the body of a for loop. An AST checker is the way to go because detection depends solely on the syntax of the code itself and not runtime behavior.
See the example below:
| Incorrect: | Correct: |
| for( i – 0; i < 10; i++ ) doSomething( ); |
for( i – 0; i < 10; i++ ) { doSomething(); } |
To flag this violation, we need to instruct the checker to find all instances of for loop nodes that contain a Statement node as an immediate descendant.
A tool that shows you a visual representation of the AST for the test case is quite helpful in the checker creation process. Here at Klocwork, we use Checker Studio to:
- browse the AST structure of test cases,
- identify nodes of interest, and
- test XPath-like expressions that identify node types, qualifiers, conditions and variables to traverse the AST and flag the defect.
Note: If we wanted to enforce the compound statement rule in all loops, then we’d need to have one pattern (created using the XPath-like expression) for each possible kind, such as while loops and do while loops.
Armed with the test case, Checker Studio, and a syntax guide, Steve identified the following expression that flags the infraction:
// ForStmt [not (Stmt::CompoundStmt)]
Here’s how the test case and expression appear in Checker Studio:
Golden rules
Based on his experience, Steve has a number of golden rules that get you from idea to defect detection faster:
- Start simple: Use a simple test case that contains the defect you want to detect and work with one simple pattern at a time. Add more complexity as you go along
- Start rough and refine later: Don’t worry about false positives at first. In some cases it may even be easier to search for instances that are OK and then negate the rule at the end
- Divide and conquer: With a more complex checker, work separately on each aspect of the defect you want to detect and then bring it all together at the end for testing in Checker Studio
- Watch your levels: Make the highlighting as relevant as possible for the issue you’re trying to find. For example, “// ClassType [MemberDecls[*]::MemberDecl]” will highlight classes that match, whereas “// ClassType/MemberDecls[*]::MemberDecl” will highlight class members that match. The rule is the same, but the focus is different
- Weed out false negatives: Add negative examples (good code) to check for false negatives
For more information about our custom AST checkers, watch our Checker Studio video.
