I would rather put complexity in FileMetric. Multiple tools can send
FileMetric data. For example, for the same file, there could be more
than one entry:
entry1: file1: pMap="size=10"
entry2: file1: pMap="complexity=10000"
Then it's DailyProjectFileMetric's responsibility to put them together.
We don't have to change its interface, only the internal algorithm needs
to be changed.
Cheers,
Cedric
Philip Johnson wrote:
--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
