Metrics how-to

How to get started with software metrics? Here are a few practical ways to use metrics to accomplish everyday tasks.

How to get a quick start?

When you need a quick start to the metrics on your code, get the Project status report.

How to measure coding productivity?

Save metrics at certain time intervals, such as once a month. Alternatively, analyze historical versions of a project.

Open the project in the "Project in time" tab. Choose Change/day in the combobox at the top.

Use the metric LLOC/day to evaluate how many real lines of code were added per day. Remember that this metric doesn't take comments, whitespace or modified/deleted code into account.

Choose Metric values in the combobox at the top. Verify that the metric DEAD has not increased significantly. This metric tells the relative amount of dead code. If it has increased dramatically, a lot of the new lines of code may actually be dead. If it has decreased, the developers have spent their time removing dead code, which is a good sign and explains why LLOC/day could be low.

Besides DEAD, the value of dLINES is also worth looking at. This is the number of lines in dead procedures.

How to verify that the code is properly commented?

Open one of the project-level tabs. See the latest value of MCOMM%. This value tells the number of real comments per lines of real code. A value of 20% tells that for each 5 code lines there is one real comment.

You can find the files that need more comments in the File tab. Again, look at the MCOMM% column to find which files have too few comments.

How to convince the boss?

Take the Project status report.

How to find procedures that require extensive testing?

We assume that a procedure that executes complex code or a procedure that is heavily used by other procedures is likely to require more testing.

Open the Procedures tab. Find the columns LLOC, LLOCt, IC1, CC and SFIN. Click on each of these columns to sort the data in ascending or descending order. View the procedures having the largest values in these columns. These are the procedures that should be tested more than the others.

LLOC. Large procedures are always worth testing.
LLOCt. A large LLOCt indicates that the code that executes via a call to this procedure is large and/or complex.
IC1. A very high value in this metric means that the procedure is a stress point what comes to data read and write.
CC. This metric equals the minimum number of test cases required to execute all the code in the procedure. A high CC indicates a complex procedure.
SFIN. The higher SFIN, the more the procedure is used within the project. Make sure that the procedure performs well under all possible circumstances.

How to find procedures that might benefit from optimization?

Open the Procedures tab. Find the columns LLOC, PARAMS, DLOOP and SFIN. Click on each of these columns to sort the data in ascending or descending order. View the procedures having the largest values in these columns. These are the procedures where optimization efforts could be more beneficial than elsewhere.

LLOC. Large procedures are always worth optimizing.
PARAMS. If the number of parameters is very high, you may need to consider making it lower to reduce calling overhead.
DLOOP. The lines of code deep within loops are likely to be executed a large number of times, demanding processor time.
SFIN. The higher SFIN, the more the procedure is used within the project. Make sure that the performance is adequate.

How to find incomprehensible code?

Open the Procedures tab. Find the columns LLOC, PARAMS, CC, DCOND, IFIO, IC1 and SYSC and SFIN. Click on each of these columns to sort the data in ascending or descending order. View the procedures having the largest values in these columns. These are the procedures that are likely to be harder to understand than the others. You may need to split or rewrite some of the procedures. You might also do by adding comments to procedures whose MCOMM is low.

LLOC. A large procedure does a lot of things.
PARAMS. Verify that all parameters are commented and well named. Are there any superfluous parameters?
VARS. An excessive number of local variables indicates a very complex procedure or bad coding.
CC and DCOND. This procedure has a lot of conditional statements or nested conditionals, possibly hard to understand.
IFIO and IC1. High values of these metrics indicate high data read/write.
SYSC. A high system complexity is just what the name implies.

How to find exceptionally bad (or good) code?

Select the metric you wish to use by moving the cursor on its column. Sort the data by clicking on the column header. Look for outlier values. Outliers are values that are higher or lower than most other values in the data set. Thus, the code may be exceptional in some sense. You can view the outlier limits at the bottom of the main window. Values below or above the shown limit(s) are considered outliers. Repeat this for the metrics you want to use to detect all outliers which could be problematic code.

How to compare teams?

Suppose two teams are working on two projects. You can use Project Metrics from time to time to compare their status. Pick the Latest analyses tab and view the following metrics:

LINES. Which of the teams has the larger project?
MCOMM%. Are both teams commenting their code as they write it?
DEAD. The deadness index shows how much dead code there is in a project. The other team may be leaving lots of dead code behind as they change the program.
LEN. Is the other team using shorter names and thus producing more incomprehensible code?
AHF. Do the teams differ in their ability to encapsulate data in objects?
LLOC/file. Is the other team writing lots of small, manageable files where the other team produces gigantic, unmanageable files?
LLOC/proc. The same question for procedures: small, manageable procedures vs. miles long spaghetti procedures.

How to evaluate work done last month?

Suppose you want to perform a monthly evaluation of your project. You can accomplish this by storing metrics at fixed intervals (say, on the 1st day of each month) and taking a look at the Project in time tab of Project Metrics.

LLOC. How much actual code was added?
LLOC' or MCOMM. How many comments were added?
MCOMM%. Is the level of commentation still high enough, or is it dropping?
dPROCS, dVARS, dCONST. Is new dead code emerging? Or perhaps, is the project getting cleaner month by month?
LEN. Is naming keeping consistent with earlier efforts?
FILES and LLOC/file. If the project got lots of new lines, did the additions go to the old files or were new files added as well? If FILES has increased, this would indicate new modules being added or old library modules being reused. On the other hand, if LLOC/file has increased and FILES has not, this would indicate additions to old code.
CC/proc. Is the code getting more complex in time? Should you refactor the most complex parts into smaller, more manageable parts?

How to collect metrics?

Standardize the collection of metrics. When your metrics process is standardized, you can monitor how the metrics develop in time and how your projects compare to each other.

Timing. Analyze and store metrics at certain time intervals, such as once a month, at significant project milestones or version releases.
Options. Always use the same Project Analyzer analysis options. We recommend that you select all source files but no binary COM or DLL files for the analysis when you're collecting the metrics. This will allow you to focus on your own source and ignore any changes in 3rd-party libraries.
Version. When you want to compare projects or different versions of the same program, use a single version of Project Analyzer to store all the metrics. Improved code analysis and changes can affect the values you get, leading to wrong conclusions about the quality of your code.

How to add speed to Project Metrics Viewer?

If you are experiencing slow performance with Project Metrics Viewer, limit the amount of data shown:

Remove databases from the search path(s) in File|Databases.
Select a smaller number of metrics to view in Options|Selections.
Uncheck Options|Display charts

Project Metrics