This section gives us an idea of how many things there are of a certain type. These can be useful indicators too. For example, if the number of Namespaces is low, there may be a lack of grouping, which is bad for discoverability. It'll be hard to find out where a certain piece of logic can be found in the code. Too many namespaces, relative to the number of Classes/Interfaces/Traits, is not a good sign either. I would expect every namespace to have a couple of classes that naturally belong together.
The number of Traits is expected to be low compared to the number of Classes. Traits are rarely a good solution in my opinion. The number of Interfaces is expected to be higher, I'd say roughly about 1:5 compared the number of Classes. Not every class needs an interface, but a lack of interfaces usually shows a lack of abstraction too, in the sense that code will be directly coupled to libraries, frameworks, databases, remote services, etc.
Structure Namespaces 3 Interfaces 1 Traits 0 Classes 9
Classes are further divided into Abstract Classes and Concrete Classes. In general, the number of abstract classes is expected to be low. If it's high, compared to the number of concrete classes, this is often a sign that inheritance is (wrongly) used for code reuse.
Abstract Classes 0 (0.00%) Concrete Classes 9 (100.00%)
It would be useful to have an indication of the use of the
final keyword. We could then easily verify the rule that all classes should either be abstract (meant to be extended) or final (meant not to be extended).
What's also missing in the statistics is a section about the actual use of inheritance. It would be interesting to have the following numbers:
Minimum class hierarchy depth 1 Average class hierarchy depth 1.2 Maximum class hierarchy depth 6
Whenever I find the time for that, I'll try to add these extra metrics to phploc itself.
The number of Methods isn't particularly interesting, but it would be nice to have some extra metrics here as well:
Minimum number of class methods 1 Average number of class methods 2.5 Maximum number of class methods 10
The Scope of Methods is relevant. As explained in part 1 I would want the number of static methods to be very low. The number of Public Methods or Non-Public Methods isn't that insightful in my opinion. It would be good to know the number of protected methods, since those would be better off as private methods. However, in service classes I think private methods are often better off as public methods of collaborator objects. So, we can't really conclude much based on these numbers.
Methods 130 Scope Non-Static Methods 130 (100.00%) Static Methods 0 (0.00%) Visibility Public Methods 103 (79.23%) Non-Public Methods 27 (20.77%)
As mentioned in part 1, the use of Named Functions should be limited. Anonymous Functions aren't a big problem, because they are used for providing
callable arguments, or to work with higher-order functions.
We discussed the use of global constants above. In this section we can compare the use of global constants to how many have been defined.
Functions 0 Named Functions 0 (0.00%) Anonymous Functions 0 (0.00%) Constants 0 Global Constants 0 (0.00%) Class Constants 0 (0.00%)
What could be added here is a subdivision of Public Class Constants and Private Class Constants (again, it's on my to do list). Public constants often lead to undesired coupling, so they should be defined as private, whenever possible.
We've reached the end of the phploc output. I hope there were some useful suggestions here, and I hope you'll take a look at phploc yourself and run it on your project.
One of my clients asked me whether you could use phploc output as a way to monitor the quality improvements made to a project over a longer period of time. I think you can. If you'd like to work on some kind an automated solution, check out phploc's JSON or XML output formatter. And please share your experience with us.
If you use phploc metrics as quality indicators in other ways than I described in this post, please share them in the comments as well.