Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VerveineJ should export some metrics #476

Closed
seandenigris opened this issue Aug 3, 2015 · 8 comments
Closed

VerveineJ should export some metrics #476

seandenigris opened this issue Aug 3, 2015 · 8 comments

Comments

@seandenigris
Copy link
Contributor

Originally reported on Google Code with ID 476

Compute cyclomatic complexity,lines of code, number of statements from AST

Suggested by Alex and Doru

Reported by anquetil.nicolas on 2010-11-03 11:00:26

@seandenigris
Copy link
Contributor Author

Reported by anquetil.nicolas on 2010-11-03 11:07:20

  • Labels removed: Component-XML

@seandenigris
Copy link
Contributor Author

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

Reported by anquetil.nicolas on 2010-11-16 21:40:05

  • Status changed: Fixed

@seandenigris
Copy link
Contributor Author

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

Reported by tudor.girba on 2010-11-16 22:02:59

@seandenigris
Copy link
Contributor Author

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).

Reported by anquetil.nicolas on 2010-11-17 08:38:29

@seandenigris
Copy link
Contributor Author

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).

Reported by anquetil.nicolas on 2010-11-17 08:39:14

@seandenigris
Copy link
Contributor Author

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.

Reported by tudor.girba on 2010-11-17 09:01:19

@seandenigris
Copy link
Contributor Author

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 .... ?

Reported by anquetil.nicolas on 2010-11-18 13:11:52

@seandenigris
Copy link
Contributor Author

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.

Reported by jfabry on 2010-11-18 13:38:24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant