What are software metrics?

This might be a term you have heard before. Simply put, they are a way to quantify aspects of source code.

These aspects vary, and each have a different significance. ... it will make more sense if you see some examples:

• LOC - Lines of code. This metric is simply the line count per file, per project, per function, per class, etc. Its value is that you can determine when code is growing beyond control. The refactoring remedy is to split up the file/class/method into smaller, more manageable parts.
• NSM - Number of static methods/fields. Excessive use of the static modifier is an indication that something is amiss. The refactoring remedy may include using a Singleton design pattern, or reworking the class design.
• LCC - Lines of comments. This is the total number of lines of comments. When taken in ratio with the lines of code, you get a vague idea of how well documented your code base is. It is a fairly common practice to generate API documentation from source, so this metric can be especially valuable if the project is a library.
• VG -Cyclomatic Complexity. This metric is not as complex as the name sounds. It is simply the count of the possible linearly independent paths the code may take. Every IF, FOR, WHILE, DO, CASE and trinary operator increments the count. This can help identify poorly written code (ie huge if-else statements), as well as potential slow spots.
• LCOM - Lack of Cohesion of Methods. LCOM is a formula for detecting the cohesiveness of a class. It can indicate when it may be time to split a class into two or more specialized classes.
• DIT - Depth of inheritance tree. This metric is the number of levels a class is sub-classed. On its own, the value doesn't necessarily indicate a need for refactoring, unless the base class wasn't designed for such a task.
• NORM - Number of overridden methods. NORM can be useful for detecting classes that have evolved beyond their original design. It might indicate better abstraction is needed at a low level.
• NOM - Number of methods. The number of methods can be useful for detecting when a class has become over grown.
  

This is only a partial list of some software metrics that can identify weak spots in your code base. It is also certainly possible to dream up software metrics of your own, such as the number of preprocessor "#if" statements used.

How to harness software metrics

All these numbers are quite meaningless without context. What is needed are tools. An ideal tool should run the software metric calculator on every file that is checked into a software repository. The metrics could then be stored and compared per file, and an action could be taken when a particular metric threshold has been crossed. From that trigger an appropriate action could be applied, such as sending out an email to the project manager, or creating a JIRA task to refactor the file. By using the type of metric, a list of possible refactoring remedies could be supplied to steer the developer on the right track.

Another desirable feature would be instant red/yellow/green status on projects and individual files, and trend when refactoring will be needed as metric counts increase. This would be the real power of such a system, being able to see instantly when a project is becoming "design sloppy" and being able to forecast early and schedule time for the issues to be refactored.

Most managers don't like refactoring. It's unpredictable, and has no immediate beneficial output. Experienced managers know that refactoring early is key to keeping a large code base manageable, and will save them time down the road. Using software metrics, you can take such abstract and intangible notions, and turn them into hard numbers. Those hard numbers can then be used for prediction, and prediction is the key to getting software estimates right. This is the most vital step to get right for a software outsourcing company.


Some useful tools for generating software metrics:

• Eclipse metrics plugin
  
• CCCC (C++, Java)