Software metrics are measurements of aspects of your software development process. Measurement is vital to this process - without measurement you cannot understand its faults, see whether improvement can be made or know whether any changes that you have made have caused that improvement to occur. You can measure a number of different aspects for any given software project -

• The amount of time that it takes you to develop
• The amount of software developed
• The time spent maintaining your software
• The number of faults
• The inherent quality of your software

We are going to concentrate on the last entry on that list - the inherent quality of your software. Apart from the amount of software developed this the only item in the list that can be assessed in an objective way from the code. The process of taking code and analysing it is called 'static analysis'. A number of metrics have been developed over the years that can give you a view of aspects of your software. The problem is that there are quite a lot of them - many of them either fully or partially duplicate others, others have the same name but may be calculated in a number of different ways, some contradict others and most of them are poorly understood by those who use them.There is a wide variety of information about these various metrics but it tends to be widely scattered and in some cases conflicting. This document aims to draw these strands together to allow you to make sensible decisions based on the results of analysis of your code by tools such as JHawk. A list of further reading is supplied at the end of this document for those who wish to learn more. Later we will try to give an overview of the most common of these metrics but first we want to look at what most of us want to achieve with metrics.

After a bit of experience in a particular language we can tell good code from bad. We can run our eyes over a piece of code and suggest improvements. But like many subjective intellectual human activities it is difficult to teach a machine to do this successfully. Look at the two samples of code below -

• public static double zzz(double x, double z) {
   z+=(z*x/100);
   return z;
  }
• public static double addInterestToBalance(double interestRate, double balance) {
   /* Add interest to balance */
   balance+=(balance*interestRate/100);
   return balance;
  }

Most competent Java programmers will accept that the second example, while functionally identical to the first, is a far better piece of code. The question is - why do you think it's better? One thing is that the second piece of code is easier to read and appears to tell you what it is doing - ie. the second piece has meaningful comments and meaningful identifiers. At least you might think so - but what if you found this line in a class called ManageHeartRate -

  if (heartRate < 70) stimulantDose = MedicalUtilities.addInterestToBalance(10,stimulantDose);

Does the code still make sense here? Is it the calling code that is wrong or should the method be changed to take account of the circumstances in which it is found? So a lot of the things that we view as 'good' in a piece of code are contextual. This means that we are going to be limited in what we can sensibly analyse using software.

Lets say we were to perform an anlysis of the pieces of code above - one of the things we might choose to count could be the number of comments. We would then see that there no comments in the first piece of code. However we could add a comment - say "/*HGHGHJGHJGJGHJGJGHJGJHGHJGJGJGJGJHG*/" - that would add nothing to our understanding of the code. Similarly we could measure the length of the variable names - but I could change X to XDGSADGFDS and while it would be longer it would still be meaningless.The trouble is that we can't easily tell a machine how to make the kinds of distinctions that we can make in just a single glance.

So, having seen that some things are not easy to measure objectively, what are the kinds of things that we can usefully measure by taking a piece of code, breaking it down into its constituent parts and measuring the numbers of these parts and some of their aspects? We'll take a look at the measurements that we can take at Method, Class, Package and System level. We define the System level as all of the code in the project that you choose to examine as a collective entity - i.e. if you were using JHawk it would be all the files that you selected for analysis.

JHawk is in use in both commercial and academic environments worldwide. You can find references to academic studies that have used JHawk here