This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Many uses of metrics use Source Lines of Code (SLOC) to compare things against. For example, currently the Netbeans core module currently has by far the most defects assigned. Notwithstanding the probably fairly low accuracy of Issuezilla issue counts (e. g. almost all these core bugs are P3, so what do we need the other Ps for :-), it would be a useful piece of information to compare issue counts against code size. So perhaps the number of bugs is simply so big because there's so much code. While there are many many problems with the metric, and it can easily be abused (this of course holds for any other metrics as well), I think it would make a worthy addition to the metrics module. Even mere counting of lines (without needing precise definition of whether to include comments, blank lines, and exactly what a SLOC is) would serve as a good start. Currently, the given metrics are hard-coded, and it is planned that they become dynamically loadable. Perhaps this metric would be a good testbed for that idea. Also, the current metrics depend solely on analyzing the byte code. SLOC would require decoupling the analysis from class files.
<i>Also, the current metrics depend solely on analyzing the byte code. SLOC would require decoupling the analysis from class files.</i> That's only true if you want a total line count of the source file. One can count the number of lines containing source that actually translate into code by counting the number of line number entries in the classfile.
I'd like to create this as an example module showing how to extend the metrics module.
The metrics module now has the ability for developers to easily create and plug-in new metrics without having to modify the metrics module itself. Check out the metrics/examples directory for an example metric you can use to create this metric.