A metrics glossary, explanations and recommandations

[theofidry]

PhpMetrics provides a lot of useful metrics. However:

• It's hard to remember the meaning of all the metrics, having a glossary page with a brief explanation and a link would be great. Not just on the website, but on the report to not have to go back and forth to the doc each time
• It would be great to have a way to expand/sort the "Explore" table. Search per name, sort by CC... Make it more usable. Right now having to open each section to find your file is a bit tedious

And please don't take that as a complain, it's a great tool already, we just want to make it the best :sparkles:

[Halleck45]

Hi @theofidry ,

The first difficulty is... the language. I can write documentation in french, but I need help for translation...

[theofidry]

That is something I could help with, even if my english is far from being perfect :)

Actually you could do a PR for it, letting the French bits, and then we translate in the PR bits by bits, like that other people could help as well.

[YuraLukashik]

+1

[pavarnos]

+1 this would be awesome. I don't know french, but am happy to review / tweak the english if it is helpful. Can we also have the glossary items as tool tips so when you hover a term it shows the definition with a link to the formula and a deeper explanation? This would really help when showing the graphs to non technical people

[theofidry]

Another great thing would be to be able to give some recommandations for the project: hey this number has a very high CC, or this package is pretty unstable and so on...

But I would say a good explanation on the numbers would be a big step already :)

[pavarnos]

Yeah would be cool to have it pick out the 10 most complicated classes or the 5 most coupled or the 7 files most likely to have bugs in etc.

@Halleck45 has been writing some extensions recently eg phpmetrics/SymfonyExtension. Could use the same idea to add this feature, and allow configuration of what you want reported without complicating the main project too much.

or maybe some d3 magic can do it (but how would the treeview work then?)

[theofidry]

@Halleck45 has been writing some extensions recently eg phpmetrics/SymfonyExtension

To me this should be part of the main project: forms or twig are not Symfony specific. And then you could have a ZendExtension, LaravelExtension... And for each (Symfony included) you have no guarantee of how the project is organised, so relying on a framework convention are not a good idea IMO.

[pavarnos]

Should I make a pull request for the analysis part? Im waiting to see if my PR for #188 will be accepted

[theofidry]

@pavarnos you should remove your number from the comment :o