yegor256 / cam

Classes and Metriсs (CaM): a dataset of Java classes from public open-source GitHub repositories
http://cam.yegor256.com
MIT License
23 stars 38 forks source link

groups of metrics #238

Closed yegor256 closed 2 weeks ago

yegor256 commented 7 months ago

There are too many metrics already in the repository, it's hard to read the final report and dataset. Let's introduce "groups". Every metric, when it's generated by a script in the metrics/, may print it this way:

foo 999 This is a good metric
abc 999 [X1] This is a good metric

Here, foo doesn't belong to any group, while abc belongs to the X1 group. Then, in report.tex, we should list them by the groups, instead of a single long list.

Raleksan commented 1 month ago

@yegor256

Hi, I would like to take on this issue.

If you support the idea, I will spend some time drafting a solution and then open a PR to discuss the details.

yegor256 commented 1 month ago

@Raleksan sure, please go ahead

Raleksan commented 1 month ago

@yegor256

I thought about it for a while and now have some questions:

  1. Is it possible to implement metrics groups only at the level of report generation? I think we don't need them at the moment of metrics collection.
  2. For now I plan to use .conf file with Metric=Group relations, what do you think about it?
yegor256 commented 1 month ago

@Raleksan I believe, it'd be better if we let metrics/*.sh files print the information about groups, instead of keeping this configuration in separate files. We would have higher cohesion of design: when, for example, group will need to be changed, it will have to be changed right where the data is generated.

Raleksan commented 2 weeks ago

@yegor256

You can probably close this issue at for now.

yegor256 commented 2 weeks ago

@Raleksan thanks!