Annotations for enforcing cyclomatic complexity and LCOM constrains

Question

Hello all,

At work we are using several tools to capture several metrics (mostly cyclomatic complexity and LCOM). We use those to get warning flags and to guide pre-emptive refactoring efforts. It's been very beneficial in increasing code quality.

However, the process is not tied to the build process. It is conducted separately. Moreover, I'm looking for something that can be made intrinsic to the source code (as opposed to an external process ran on it.)

Is anyone aware of a group of annotations and configurable annotation processor(s) that can be run from the compiler, and which will make the build fail if code doesn't comply with threshold cyclomatic/LCOM metrics?

I guess I could run ckjm, checkstyle and pmd from maven/ant, BUT some work on source code, and others work on bytecode. It would be nice to have one consolidated tool that works on the source code before compilation begins.

The other thing is that it'd be nice if there are sets of annotations that could drive this (to allow customization that will be inevitably be needed for corner cases.)

@LCOM3(Threshold=1.5)
public class SomeDumbPojo {... buch of gets/sets...}

// by default would be measured against a strict LCOM3
public class ActualBizClass
{
   @CYCLOMATIC_COMPLEXITY(Threshold=15)
   public void someFatIrreducibleMethod(){...}
}

Then, when we run the tool, by default applies strict (and configurable) metric threshold except on those artifacts that are annotated with (hopefully documented and legitimate) more relaxed thresholds. For some methods that cannot/should not be reduced, a relaxed cyclomatic complexity makes sense. For plain POJOs w/o behavior, LCOMs need to be relaxed... and so forth and so forth.

Looking and googling as I might, I have not been able to find anything (hopefully open source). But I might as well ask here just in case anyone is aware of anything of the sort.

Thanks.

Answer 1

It would be nice to have one consolidated tool that works on the source code before compilation begins.

I'm not quite sure what this means as the code has to be compiled into something in order for static analysis to work. All of these tools need to be able to compile your code either into bytecode or some sort of syntax tree.

I would suggest keeping it simple: configure PMD to fail the build if any warnings for Cyclomatic Complexity or other metrics cross a given threshold. Instead of annotating the method with the allowable complexity (how would you derive an accepted value? what's to prevent someone who accidentily increased the complexity from 12 to 15 to just bumping up the annotation), annotate it to suppress the warning completely

@SuppressWarnings("PMD.CyclomaticComplexity")
public void someFatIrreducibleMethod() { ... }

And then periodically you can search your codebase for methods with suppressed warnings that you might want to remove and refactor.

Alternatively, PMD has support for leaving comments in the code in a certain syntax to mark who audited the warning and when, if you'd like to provide some sort of traceability.

Answer 2

The SD Java Metrics tool computes most basic metrics (not LCOM but certainly Cyclomatic complexity), and runs from the command line.

It produces an XML output file, with detailed metrics on methods and rollup summaries for hierarchies above that (class, package, subsystem). Using XLST (or awk or perl or...) It'd be very easy to extract the metric you want for the full summary or for an individual method, and check against your threshold.