This morning I was thinking about the state of the computer industry and I have to say I fell pretty good about the direction many of us are moving in. Agile processes are all the rage in the enterprise, Unix is a mainstream operating system, there is an excellent and very pragmatic Lisp tutorial, and the semantic web is entering the public eye.
This is a great time to be a technology craftsman.
The good folks at Agitar have proposed a new metric, C.R.A.P and an Eclipse plugin crap4j for executing it.
C.R.A.P. combines a method’s complexity with its coverage to come up with a single number that can help you determine if somebody will say, “Oh crap!” when they have to work with it. The formula is:
CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)
Read their article for details on deciding if a system is crappy or not.
To test the flexibility of Panopticode I decided to implement a C.R.A.P. Supplement. It took a little over an hour.
Looking at the results I was pleased to find that only one method in Panopticode exceeds Agitar’s C.R.A.P. threshold of 30. Unfortunately that leads me to believe that 30 is too high. Right now, there is a lot of spike code in Panopticode right now that I consider crappy ;->
In the last post we learned that Panopticode 0.2 will allow us to create arbitrary reports using a SPARQL SELECT query. Another feature in Panopticode 0.2 is to use a SPARQL ASK query to break the build.
An ASK query looks very similar to a SELECT but without any elements to return. If the query matches any data it returns true, otherwise it returns false.
Rewriting last post’s SELECT query as an ASK query would look like:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX panopticode: <http://www.panopticode.org/ontologies/panopticode#>
PREFIX java: <http://www.panopticode.org/ontologies/technology/java#>
PREFIX emma: <http://www.panopticode.org/ontologies/supplement/emma/1#>
PREFIX javancss: <http://www.panopticode.org/ontologies/supplement/javancss/1#>
ASK WHERE
{
?package rdf:type java:Package .
?package panopticode:name ?packageName .
?package java:hasFile ?file .
?file panopticode:filePath ?filePath .
?file java:hasType ?class .
?class panopticode:name ?className .
?class java:hasExecutableMember ?method .
?method java:methodSignature ?methodSignature .
?method emma:hasLineCoverage ?lineCoverage .
?method javancss:cyclomaticComplexity ?ccn .
?lineCoverage emma:coveredPercent ?lineCoveragePercent .
FILTER (?ccn > 1) .
FILTER (?lineCoveragePercent <= 80.0)
}
Panopticode 0.2 will come with an Ant task that automatically breaks the build when an ASK query returns true.
In Metrics Must be Interpreted In Context I described one of my preferences when creating rules around metrics. Namely, that one should not look at metrics independently, but within the context of other metrics. I described a rule that said unit test line coverage must be greater then 80% for all code with a cyclomatic complexity over 1. While you could enforce this rule in Panopticode 0.1 by creating a custom report, this is not ideal. Who wants to write Java code every time you make a new rule? This will get much easier in Panopticode 0.2.
Panopticode 0.2 has been re-architected to use RDF as it’s file format and internal data store. This enables you to write queries using SPARQL. Here is a query to find violators of the rule mentioned above:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX panopticode: <http://www.panopticode.org/ontologies/panopticode#>
PREFIX java: <http://www.panopticode.org/ontologies/technology/java#>
PREFIX emma: <http://www.panopticode.org/ontologies/supplement/emma/1#>
PREFIX javancss: <http://www.panopticode.org/ontologies/supplement/javancss/1#>
SELECT ?packageName ?filePath ?className ?methodSignature ?ccn ?lineCoveragePercent
WHERE
{
?package rdf:type java:Package .
?package panopticode:name ?packageName .
?package java:hasFile ?file .
?file panopticode:filePath ?filePath .
?file java:hasType ?class .
?class panopticode:name ?className .
?class java:hasExecutableMember ?method .
?method java:methodSignature ?methodSignature .
?method emma:hasLineCoverage ?lineCoverage .
?method javancss:cyclomaticComplexity ?ccn .
?lineCoverage emma:coveredPercent ?lineCoveragePercent .
FILTER (?ccn > 1) .
FILTER (?lineCoveragePercent <= 80.0)
}
ORDER BY DESC(?ccn) ?lineCoveragePercent ?packageName ?filePath ?className ?methodSignature
Marty Andrews has just released version 0.12.0 of Complexian. This version adds the ability to output to plain or XML files.
Complexian is a tool for very quickly measuring NPATH and CCN of Java projects. It will be free for use until the first major release.
Support for executing Complexian is already in Panopticode’s Subversion repository and full support will be in release 0.2.
Panopticode 0.1 is now available.
While there are still some rough edges, this release provides:
I would like to thank all of those who have helped make this release possible: Chris Turner, Peter Sestoft, Alok Singh, and Jeff Bay.
James Newkirk points out that the absolute measurement of code coverage is not a very interesting number by itself, but must be viewed as part of the overall trend of coverage. He also points out that it is acceptable for some categories of code to have lower, or even zero, test coverage.
These are examples of one of my fundamental rules of metrics.
A few examples of context are:
There is a lot more to say on this subject. Stay Tuned.