Mike, Cedric, Cam, and I met for the Hackystat Size summit today. Here's a summary of
our results:
* When thinking about size metrics in Hackystat, there are a variety of levels upon which
to ponder, including:
- Size tools. Currently or soon-to-be supported tools include:
LOCC (Mike). Java grammar-based parsing, provides 'sophisticated' size counts and
OO metrics.
C++ size support, minimal size data (comment/noncomment
lines)
SCLC (Cedric). Over a dozen languages, minimal size data
(comment/noncomment lines)
Cam's Parser. C++, does minimal size plus number of functions in the file.
- Size sensors. We currently have a sensor for LOCC only. Goal: a generic FileMetric
sensor.
- FileMetric sensor data type. The current FileMetric Sensor data needs a redesign. See
below.
- Server analyses, including DailyAnalysis, DailyProjectData, and Reduction
functions.
These tend to be too Java-specific. See below.
The delegates to the summit came to the following conclusions:
1. With the advent of evolutionary sensor data types, we will be able to redesign the
FileMetric SDT. Our proposed new structure is:
- Required attributes: - Selected optional (plist) attributes (used by public
analyses):
tstamp sourceLines
tool commentLines
fileName functionCount
fileType functionSizeList
nonblankLines lastMod
totalLines className
This new structure satisfies the following requirements:
- The required attributes provide a minimally useful 'default' size metric for any kind
of file-based source data.
- nonBlankLines can default to totalLines if the counting tool cannot determine
it.
- fileType is determined by the sensor (so that it can, say, use the first line to
detect shell script types)
- Optional attributes support the basic programming language units and metrics.
- lastMod is useful on the client-side to eliminate redundent FileMetric
entries.
- className is useful in Java for tying Unit Test data without a file but with a class
name to the fileName.
- Other optional attributes can be provided but won't probably be supported by public
Hackystat analyses.
2. We will publish the list of fileType identifiers used by our sensors as part of the
FileMetric SDT documentation so
that other sensor writers can employ them if they desire.
3. Analyses will attempt to avoid hard-coding fileType-specific analyses.
4. Rather than provide a custom sensor for each size tool considered in this analysis, we
instead agreed upon a common XML format that all tools will produce. Then, a single
generic FileMetric sensor can be used to read in this common XML and send it to the
server. The format is basically:
<filemetrics>
<filemetric tstamp="" tool="" fileName="" fileType="" nonblankLines="" totalLines=""
sourceLines="" .../>
<filemetric .../>
<filemetrics>
All of the required attributes should appear in each <filemetric> entry, and zero or more
of the optional ones can appear. Sensors are, of course, free to implement their own
optional attributes, but they will require additional analysis capabilities to be
written.
5. The steps in carrying out this redesign are:
a. Philip finishes evolutionary sensor data types.
b. FileMetric data is evolved to this new format.
c. FileMetric sensor supporting common XML format is implemented.
c. Size tools are modified to produce the common XML format.
d. Analyses are modified to operate on new FileMetric format.
Volunteers for steps (b) through (d) will be solicited following the conclusion of step
(a).
6. As a side note, one delegate to the summit (Cam) complained vociferously about the
bogosity of current UnitTest analyses, which are totally Java and CSDL specific, and
effectively require each unit test to have an associated FileMetric entry identifying the
fileName associated with the test. The other delegates responded with thundering
applause to this denouncement. Be it resolved: As soon as we clean up size, we are going
to move on to unit testing!
Submitted for your approval.
Philip
Secretary, Hackystat Size Summit
August 2005
