Background
In our project we have been trying to automate as many things as possible. One thing which we are yet to do is to incorporate code metrics into our automated build process. As part of Agile process it is suggested that we should automate as many things as possible. Code metrics is an optional feature but I personally believe that it helps a lot in designing quality code and also maintaining it. In this post I would like to give an overview of various software code matrices we can use to improve the quality of code. In future posts I’ll try to highlight each of them with a dedicated post.
Code metrics
Code metrics are a set of software measures that enable developers to develop better quality code. Some of the most commonly used code metrics are
Maintainability Index
Maintainability Index calculates an index based on other factors like Cyclomatic Complexity and Lines of Code to indicate how easy or difficult it is to maintain a particular class. This value ranges between 1 to 100. It should be as close to 100. Lower maintainability index means that the class is difficult to maintain.
Cyclomatic Complexity (CC)
Cyclomatic Complexity is the count of decision points in a class or a method. Usually at a class level its an aggregate of all the cyclomatic complexities of the properties and methods of that class. At the function level it is the sum of decision points in that function. Examples of decision points can be an if else construct, a looping structure like a do, do while or while loop. It could also be for and foreach loops. Decision point also include switch statements. Every time there is a decision point, it requires more code to write unit tests to cover that code. This results in higher complexity and lower maintainability. A code with large control structure is hence a more complex and less maintainable code.
Depth of Inheritance
This indicates the number of levels up to which classes are inherited or extended. It does not include interfaces. If there is multilevel inheritance, it becomes difficult to identify where are some of the properties and methods defined. At the class level this defines the depth of inheritance tree. It can also be calculated at the namespace or project level. At namespace or project level we consider only the highest depth of inheritance.
Class Coupling
Class coupling is an indicator to show the interdependencies between classes. It calculates the sum of unique classes which are referred by a particular class. It does not take into consideration the primitive types and framework classes. Class coupling will take into account the unique classes which are used in various sections of the program like parameters, local variables, base classes, interface implementations etc. This metric should be as low as possible. Higher value indicates that a class has more number of dependencies which increases maintenance costs and makes it difficult to reuse.
Lines of code (LOC)
This is pretty straight forward. It indicates the number of lines of code. It does not take into account the non executable lines such as comments, white spaces etc. If a class or method consists of too many lines of code, it might be an indication that the class or method is trying to do too much. In such cases we should try splitting it up.
Conclusion
In my personal opinion very few people make use of these matrices to improve their code quality. Many of the senior developers I come across are not aware of these at all or simply ignore them even when their favourite IDE supports it.
There are various tools available to measure the above mentioned software metrics. If you are using Visual Studio Team System (VSTS) it comes built in with code metrics feature. There are other commercial tools like NDepend and NCover. As far as I know NCover provides an option to report only Cyclomatic Complexity . Best part of using these tools is they can provide feedback in the form of graphical indicators.
For e.g. If you are using VSTS, it can show maintainability index with a green, orange or red box based on the value.
In my future post I’ll try to demonstrate each of the above metrics using Visual Studio Team System. Till then Happy Programming :)
Hey Nilesh, i agree with you that many developers in the .NET arena dont even bother to know about these things. Even TDD is done the reverse way. i..e code the function then write 2 test - one happy path and one exception path :)...These tools speak a lot about how you code but i think its a human tendency to think that what i wrote works so why look into these :)...
ReplyDeletekeep writing man
Good post. Of course, most metrics must be taken with a grain of salt because automated results can sometimes be deceiving. For example, to make code more testable we may have break out functionality into separate classes, which would create more coupling. This would increase cohesion and improve the code quality but the tool may indicate the quality is lower than if we kept the functionality in the same class.
ReplyDeleteI am a big believer in code quality; I blog and teach on it regularly. However, there are times when we want to violate code qualities, for example for performance or security. If we are losing some code quality to gain something else that is more important than it is alright. The important thing is we always start with writing quality code and have valid reasons to make compromises.
Metrics can be helpful. I particularly like tools that report test coverage. I always write my tests first so I get 100% test coverage but sometimes when I refactor I may miss some coverage so it is nice to have a tool double check for me.
In agile development we tend to not focus on metrics as much as in waterfall. The only real metrics we need to focus on in agile is time to value, which we usually measure in team velocity for burning down story points.
Cheers,
David.
Nilesh I am impressed with your articles.Can you put few lines on High level design metrics and detailed level design metrics with reference to code,quality etc
ReplyDeleteWonderful goods from you, man. I've understand your stuff previous to and you are
ReplyDeletejust too magnificent. I really like what you have acquired here,
really like what you're saying and the way in which you say it.
You make it entertaining and you still take care of to keep
it wise. I can't wait to read much more from you. This is
really a wonderful website.