Re: Issue 476 in moose-technology: VerveineJ should export some metrics

Updates:
        Status: Fixed

Comment #2 on issue 476 by anquetil.nicolas: VerveineJ should export some  
metrics
http://code.google.com/p/moose-technology/issues/detail?id=476

Cyclomatic complexity and number of statement done for methods.
number of line of cade is available for classes and methods through the  
attached FileAnchor which gives the first and last line of an Entity

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #3 on issue 476 by tudor.girba: VerveineJ should export some metrics
http://code.google.com/p/moose-technology/issues/detail?id=476

Great news. But, please for compatibility reasons, it would be great if  
Methods could export LOC as a property, and Classes WLOC.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #5 on issue 476 by anquetil.nicolas: VerveineJ should export some  
metrics
http://code.google.com/p/moose-technology/issues/detail?id=476

I am not sure I want to follow you on this one.

Both metrics can easily be computed from the data already available.
I would like to keep Verveine as lean as possible.

The compatibility argument does not convince me either.
I suppose you mean compatibility with infusion?
I mean no harm to infusion and it does provide good inspiration, but it is  
not a standard, it is only one tool to export java code to MSE (just as  
VerveineJ is another one).

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #6 on issue 476 by tudor.girba: VerveineJ should export some metrics
http://code.google.com/p/moose-technology/issues/detail?id=476

When I said "for compatibility" I not only meant the way inFusion does it,  
but also for the meaning is supposed to be. The source anchor of a method  
should include annotations, comments and javadoc. I am not sure what the  
status of VerveineJ is in this area, but it should be like that. However,  
LOC should ignore the javadoc and the annotations to preserve the intended  
meaning of the metric as we use it in Moose.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #7 on issue 476 by anquetil.nicolas: VerveineJ should export some  
metrics
http://code.google.com/p/moose-technology/issues/detail?id=476

In VerveineJ, I have attached the javadoc to the entity, but it is not part  
of the source anchor.

One of the issue is that I don't really have access to it. I can more or  
less reconstruct the javadoc through the list of its tags, but this is not  
the "real" comment that is in the source code.

I believe I could get the line number of the javadoc, but I am still not  
convinced that it would be the ideal solution.

I prefer the idea of doing the minimum processing (and interpretation)  
possible on the data, and leave the user decide what s-he wants to do with  
it (given that s-he has the needed elementd for that).
I added Cyclomatic and Number of Statement metrics because as you point  
out, they cannot be computed from the MSE.
I am giving the user the possibility to compute the LOC s-he wants, by  
attaching the source anchor to the code entity (did not do it for the  
javadoc, but I believe I could). From that s-he is able to compute the LOC  
s-he wants (with or without javadoc).

Anybody else as an opinion on this to try to find a consensual  
decision .... ?


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #8 on issue 476 by jfabry: VerveineJ should export some metrics
http://code.google.com/p/moose-technology/issues/detail?id=476

Two comments, thinking about extra/duplicated work:
Where would the LOC-computing code be? I use LOC in AspectMaps, Polymetric  
views use LOC ... If multiple users need to implement this in their own  
codebase, it would be better instead to have this as a feature of Moose  
itself right?

 From a Java-import-user point of view, ideally I would be able to switch  
from inFusion to VerveineJ without having to modify code (except for the  
invocation of the importer). Anything that makes the switch harder makes a  
new importer more trouble for everybody that wants to make the switch.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev