I just started to look at how to write a Hackystat sensor for the JavaNCSS results. A couple of interesting thoughts and issues came up.
is Resource enough?
what is a Resource in Hackystat? well, according to the Rest API Specification, a Resource is a "A URI indicating the resource (file, website, etc.) on which this sensor data was collected." Hmm.. Okay that seems fair enough. But, the problem I'm faced with is that JavaNCSS produces package, object, and method level metrics. Thus, it would be impossible to capture and utilize all of JavaNCSS's metrics.
for example, here is some sample data:
<package>
<name>org.hackystat.sensor.ant.checkstyle</name>
<classes>2</classes>
<functions>7</functions>
<ncss>129</ncss>
<javadocs>6</javadocs>
<javadoc_lines>32</javadoc_lines>
<single_comment_lines>19</single_comment_lines>
<multi_comment_lines>17</multi_comment_lines>
</package>
<object>
<name>org.hackystat.sensor.ant.checkstyle.CheckstyleSensor</name>
<ncss>67</ncss>
<functions>4</functions>
<classes>0</classes>
<javadocs>4</javadocs>
</object>
<function>
<name>org.hackystat.sensor.ant.checkstyle.CheckstyleSensor.CheckstyleSensor()</name>
<ncss>2</ncss>
<ccn>1</ccn>
<javadocs>1</javadocs>
</function>
so you see that package has some data that object does not (single_comment_lines and multi_comment_lines). and function has ccn (Cyclomatic Complexity Number). To satisfy Hackystat's requirement I'd just have to use the object metrics, which means missing out on the single_comment_lines, multi_comment_lines, and ccn. That seems bad to me.
Mapping inner classes to files
Currently, when the tool results do not provide the file path (ie provides a class name org.hackystat.sensors.ant.checkstyle.CheckstyleSensor), we do a matching to match the class name with a file. I'm not sure how that works exactly, but I do wonder if it works correctly for inner classes. Basically, would org.hackystat.sensor.ant.checkstyle.CheckstyleSensor.Temp (where Temp is an inner Class) map correctly to c:\java\svn\hackystat-ant-sensors\src\org\hackystat\sensor\ant\checkstyle\CheckstyleSensor.java?
I'm not sure it would.
JavaNCSS bug
Investigating that inner class issue, I found that JavaNCSS does not capture inner class metrics correctly. it seems that JavaNCSS doesn't report separate metrics for inner classes. i created two temporary inner classes within the CheckstyleSensor to test out whether JavaNCSS would handle it correctly. unfortunately, it seems the only metrics i get out of JavaNCSS about those inner classes are rolled up in existing elements, meaning i don't get a separate object element for the inner classes. instead, i get this:
<object>
<name>org.hackystat.sensor.ant.checkstyle.CheckstyleSensor</name>
<ncss>75</ncss>
<functions>4</functions>
<classes>2</classes>
<javadocs>4</javadocs>
</object>
the classes=2 is supposed to represent the two inner classes that i added. i suppose, one could argue that the inner classes belong to CheckstyleSensor and that should be okay to contain the metrics within the CheckstyleSensor object. But, wouldn't it be better if we could distinguish the metrics between CheckstyleSensor and its inner classes. anyway... i didn't particularly like that about JavaNCSS.
Anyway, a Hackystat JavaNCSS should be relatively easy to implement. i probably could have finished it faster than writing this blog. but, i wanted to hash out some issues that i was thinking about. in fact, i think i should bring up the Resources and mapping to file questions to the hackystat-dev mailing list.
No comments:
Post a Comment