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 -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
