--On Sunday, February 26, 2006 3:57 AM -1000 "(Cedric) Qin ZHANG"
<[EMAIL PROTECTED]> wrote:
(1) Migrate LOCC (Java counter portion) using PMD source code parser.
Basically, we need one visitor for one type of metric. (2) Add new types
of metric. For starters, cyclomatic complexity is already done. LOC,
SLOC, comment lines should be much simpler. (3) Use LOCC to send Java
related metrics and SCLC for other types of files during our nightly
build.
How do you guys think about it?
Well, it's an intriguing idea, but there are some other issues to consider.
(1) AFAIK, there actually wasn't a problem upgrading LOCC to work with Java
1.5. The "nightmare" with LOCC resulted from a project to obtain an
acceptable C++ grammar for the kinds of programs we were looking at
(including preprocessor directives), a task which we eventually gave up in
defeat. When Java 1.6 comes out, if it involves a grammar change, it's
doubtful it will require more than a day of work to upgrade.
(2) There is a small maintenance issue with LOCC and Java grammars, and
that results from the fact that our LOCC user community is split among
people running different versions of Java with different grammars. So, we
supply multiple versions of the system for the various Java grammars. Can
we count on PMD to support all versions of Java grammar?
(3) LOCC is also visitor-based and extensible to support metrics like
complexity. It may well be that PMD has a more elegantly implemented
extension point, and so instead of taking 30 minutes, it might take an hour
to implement cyclomatic complexity in LOCC, but I wouldn't think it would
take too much longer. I'm not saying we do this, since that would be
redundant now that you've got it in PMD.
So, the net of it is that since maintaining LOCC w.r.t. Java grammars is
not a significant cost, I don't see a significant benefit to offloading
grammar management onto the PMD project, and perhaps not worth the
migration effort.
What's of more direct interest to me, at least, is making "complexity" a
non-Java specific metric. How can we gather complexity on C++? Python?
Ruby? etc? Obtaining this capability seems like a more effective use of
our limited resources.
Finally, there's the issue of how complexity should be represented in
Hackystat. There are several options:
* Represent via FileMetric (If so, then we have to realize that we might
have one tool generating size data via FileMetric and another generating
complexity via FileMetric, which means we can't just take the last snapshot
of the day---we have to take the last snapshot of the day that actually
contains the metric of interest.
* Represent via CodeIssue (But this seems weird--"complexity" seems like a
metric, not an "issue").
* Represent via a new SDT for Complexity. (But why wouldn't FileMetric be
reasonable?)
Cheers,
Philip
