Hi Mukul,
We might want to take this offline since it's probably off topic for most
devs. Thanks for checking things out. You are correct when you state that
cyclomatic complexity is generally seen as a procedural-level metric in
the OO world.
How you combine the complexity of methods should depend on what you are
investigating. I was combining it as a surrogate for size (as a sum) which
is not appropriate to detect unmaintainable code, but better to identify
classes with many responsibilities. Using the average is inappropriate
because the presence of accessor methods will artificially lower the
complexity value. McCabe uses the max value which is reasonable to raise a
flag. BTW, we did not use cyclomatic complexity as in the god class
detection model.
In 'Object-Oriented Metrics in Practice' by M.Lanza and R. Marinescu, the
authors use the average line complexity (Complexity/Size) which is an
alternative complexity measurement.
cheers,
Stephane
On Fri, 12 Jun 2009, Mukul Gandhi wrote:
Hi Stephane,
I am not sure, how you calculated the cyclomatic complexity of the code.
I believe, we should look at the cyclomatic complexity of the methods,
and also the average cyclomatic complexity of the class (which is
average of all the methods). It may be possible that, cyclomatic
complexity of few methods of a class may be high. But the average
cyclomatic complexity of the class may be tolerable.
My measurements show that, XML11EntityScanner.java has a maximum
cyclomatic complexity of 47 (the 'scanData' method) and the average
cyclomatic number for XML11EntityScanner is 22.
I have done a quick calculation of the cyclomatic complexity of the
whole Xerces-J code (not considering the commons code). Below are my
findings:
1) 25 files, have cyclomatic complexity above 50
This is about 3.5% of code. I think, this is pretty good quality in
terms of code complexity.
2) 3 files, have cyclomatic complexity above 100 (which means, the
amount of highly complex code is very less)
XSSimpleTypeDecl.java
applyFacets - 193
average - 6
RegularExpression.java
matchCharArray - 166
matchString - 166
matchCharacterIterator - 166
average - 15
XPath.java
scanExpr - 136
average - 32
My conclusion is, that Xerces-J code has good complexity numbers. I
don't see any areas of concerns as far as code complexity is
considered.
On Thu, Jun 11, 2009 at 10:59 PM, Stephane
Vaucher<[email protected]> wrote:
Hi Mukul,
Thanks for the response and constructive comments. There were more classes
detected than those sent to the list. The subset I chose all exhibit high
levels of cyclomatic complexity.
The general problem with development guidelines is that they are rarely
based on empirical evidence that supports the choice of thresholds. Part of
my research focusses on verifying how well and under which conditions,
metrics can measure quality.
In the case of xerces, many classes would fail the SEI guidelines. For
example, a class like XML11EntityScanner has a summed complexity in the
order of 100s instead of 10-15 (# independant paths through code). Does this
mean that the code is unmaintainable? Well, despite the fact that many core
developers have left the project, the project is still under development.
IMO, the lack of development activity is due to the lack of resources and
the fact that the library already does what most users need, rather than
code quality. In any case, I'll see how the GSoC participants perform and
how easy they'll find adding code to xerces.
I'll go back to lurking, thanks for the responses.
cheers,
Stephane Vaucher
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
