Skip to main content

Code maintainability index


How do you measure that your code is maintainable?

There is no such standard measure exists in IT industry that indicates that your code is maintainable. However there can be several disciplines which you can use to interpret maintainability of your code. One way of arriving to this is to identify different high priority code metrics and summarization of weightage of each of those metrics. For example look at the below calculation,

Code Metrics
Weightge in %
Code coverage
50
Cyclomatic Complexity
20
Duplicates
10
Coupling
10
Large Class
5
Large Methods
5
Total
100
    
The above table illustrates the weightage derived from each metrics considered to calculate the maintainability index of software. The weightage can be calculated based on the target metrics you have defined for each item on the list. This calculation is quite interesting and can be applied to any code that needs serious attentions. It is mostly applied for legacy code that is hard to understand or refractor. Any such statistical representation will help to check the progress of legacy code module.

Based on the total weightage calculated, you may want to represent your software as below,
Maintainability index
Summery
0-30
Need serious attention (Bad)
30-50
Need improvements (Average)
50-70
Maintainable, can be improved (Good)
70-100
A very good maintainable code (Excellent)
  
Before jumping into this calculation it is important to decide on the target metrics that the software should be adhered to. That will basically set the goal and the trend you need to define in iterations. The target metrics can be derived from the base metrics of your current code base. Identify the amount of improvement you can do based on the base metrics and that can be converted into small iterations. Or you can add those as a technical story into your backlog. Identify or add some slack time into your iteration planning or into your estimation to address those. Following the every iteration you can have check on your maintainability index.

The above calculation I have shown is not a standard one, I have just quoted an example. The calculations and assumptions can be different to different team based on their internal understanding or discussions. However I assume that these types of measurements should be done with proper discussion with the team and also the stack holders.

Be careful while selecting the kind of metrics you are going to use for the calculation of maintainability index. Do not take too many metrics to be worked on, discuss within your team and identify 4 or 5 very important metrics that make sense to make you code maintainable and readable. Developers or Architects sometime tends to collect too many metrics but it never make any sense as most of the metrics does not have any direct impact on the maintainability of the code. For example, metrics like unused types, code comments does not have any direct impact on your code maintainability than cyclomatic complexity or class coupling. Understand the rationale behind all of them and choose the one that really helps. Others can be addressed later or will be addressed indirectly during refactoring. 


Comments

Post a Comment

Popular posts from this blog

Spring: Method Injection

This is useful when a Singleton bean need to use a non-singleton bean. Sometime your application may need to collaborate a prototype bean with a singleton bean to satisfy your business logic. That is your singleton bean is dependent on a prototype bean. Let’s consider three beans Customer Sales Person Product A customer may ask a sales Person to show different type of products from the repository. Let’s assume you have gone to a garment shop to buy a new shirt for the lucky date with your new girlfriend. So, it’s a tough choice and you may like to try different colors and styles and finally you will choose one. So, if we describe the above situation in the form of business logic inside one of your module, it will look like this, The sales Person should show a new product every time he requests. Let’s assume Customer and Sales Person to be singleton bean in your Spring container and Product as prototype. But based on bean life-cycle a prototype bean can not be injec...
Post a Comment
Read more

Copying objects – Java Clonable interface

We can assign reference of an object to another, provided each of them satisfies an “ is-a” relationship or of same type. For example, a Dog object can hold the reference of another Dog object regardless both have different states. Similarly an Animal object can hold the reference of a Dog or Cat object, if they satisfies an “is-a” relationship. But hold on, these assignments do not help you to create a duplicate copy of the object. It’s nothing but different pointers pointing to the same memory location. Java provides API to clone an object. Using this API one can get a copy of an object to another. To achieve this, proposed class should implement Clonable interface (else JVM will throw CloneNotSupportedException during runtime). The rationale behind cloning is to get an independent copy of an object. The Object class has a clone() method which takes care of this operation. This method is protected by nature and returns an Object , when called.   You can call this ...
Post a Comment
Read more

JUnit Rule : Creating Temporary Folder

I was surprised to see this beautiful feature in JUnit and it helped to ease to lots of constrains I face while writing JUnit tests. I basically follow TDD and as you guys know we focus more on writing tests, hence it is necessary to use some shortcuts availed by the tools like JUnit to make the process fast. Recently I had an issue where I had to create and delete a file before and after every test executes. I did that using @Before and @After annotation of Junit and it worked, however I was looking for more of a generic way to do this at one place. As I started googling I came across this post, which is amazing,  After reading the block I know how I can generalize my creating and deleting of a temporary file or folder (I decided to go with a temporary folder and a file inside it, which looks more readable and oganized). The JUnit class: public class TemporaryFolderTestCase { @Rule public TemporaryFolder temporaryFolder = new TemporaryF...
Post a Comment
Read more