|Object-Oriented Software Metrics - Method Level Metrics|
|Product Home||Application||Eclipse Plugin||Command Line||Metrics Guide||Download Free Trial||FAQ, News, Bugs||Other Products|
|**** Just released - JHawk 6.1.3 - See here for details - new Review Factor metric and DataViewer command line service to create motion charts (Professional licenses only) ****|
We can start at the method level with very basic things like the numbers of lines of code.This is a much derided figure as it is a popular tool at the management level - some of whom view it as a measure of productivity. I would certainly doubt its usefulness at a higher (e.g. class, package) level but at the method level I would consider it one of the most useful metrics. A big method is harder to understand. Partly just because there is more code to read but there are also 'environmental' factors -you might have to scroll up and down to see all of a method so you can't grasp all of it's meaning in a single 'eyeful'. A big method is probably big because it's trying to do too much - one of the golden rules of programming is that each method should perform a single clear distinct function. There is also the question of what constitutes a line of code - JHawk takes the approach of measuring the number of Java statements rather than the number of lines of code. This means that the programmer is free to format their code as they feel without getting penalised for adding another line (e.g. by putting a bracket or a parameter on a separate line for the sake of clarity). You can find more about our views on lines of code, comments and statements in one of our 'Sidebars' papers which you can find here.
Also at the method level we can look at McCabes Cyclomatic Complexity. This is a measure of the number of possible alternative paths through a piece of code. Low Cyclomatic Complexity can be seen in methods where one line of code simply follows another e.g. where we set a number of attributes, perform a calculation and return a value. Higher complexity values will be found in methods that have a lot of if statements, for and while loops etc. This is a pretty intuitive metric - you could look at a method and deduce whether it had a high or low Cyclomatic Complexity. It is easy to get a computer to calculate this accurately so it's a reliable metric. Cyclomatic Complexities over 10 are generally viewed as being bad.
Another set of metrics at the method level are the Halstead metrics. There are quite a few of these. They are primarily based on the number of operators (method names, arithmetical operators) and the number of operands (variables, numeric and string constants). The Halstead metrics give a sense of how complex the individual lines of code (or statements) are. The most basic is the Halstead Length which simply totals the numbers of operators and operands - a small number of statements with a high Halstead Volume would suggest that the individual statements are quite complex. The Halstead Vocabulary gives a sense of the complexity among the statements - for example are you using a small number of variables repeatedly (less complex) or are you using a large number of different variables - which will inevitably be more complex. The Halstead Volume uses the length and the vocabulary to give a measure of the amount of code written. The Halstead Difficulty uses a formula to assess the complexity base on the numbers of unique operators and operands. It suggests how difficult the code is to write and maintain. The Halstead Effort attempts to estimate the amount of work that it would take to recode a particular method. The Halstead Bugs attempts to estimate the number of bugs that there are liable to be in a particular piece of code.
The Halstead metrics have been around for some time (since 1977 in fact) - they predate object-oriented languages but are still relevant today. All of the measures are relevant at method level and can reasonably be presented as averages per method at class, package and system level. Halstead Length and Halstead Effort can reasonably be expressed as totals at the higher levels.
The Maintainability Index (MI) is a set of polynomial metrics developed at the University of Idaho, using Halstead's effort and McCabe's cyclomatic complexity, plus some other factors relating to the number of lines of code (or statements in the case of JHawk (see above)) and the percentage of comments. The MI is used primarily to determine if code has a high, medium or low degree of difficulty to maintain. It is language independent and was validated in the field by Hewlett-Packard (HP). HP concluded that modules with a MI less than 65 are difficult to maintain, modules between 65 and 85 have reasonable maintainability and those with MI above 85 have excellent maintainability.(I’m sure you will be pleased to learn that all of the code modules in the JHawk distribution have values for MI greater than 65!)
JHawk gives separate figures for MI which takes account of comments and for MI which does not take account of comments. We have two main reasons for this -
There are a number of other metrics that can give some guidance to the quality of your code at method level -
How to split methods
There are a number of good reasons to split methods which are seen as being too large -
The actual process of splitting depends on what you are trying to do and the particular algorithm that you are trying to implement.There are three main types -
Of course many of your methods will actually be combinations of these different types but you can still apply the strategies as appropriate. In any case a good rule of thumb is that the entire text of a method should be viewable as a single screenful in whatever editor you are using.
Refactoring (by Fowler) is an excellent source of patterns to use when refactoring code. Remember that if you are refactoring code a good set of unit tests will ensure that you maintain the functional integrity of your code while improving its quality. If you are not yet familiar with the JUnit unit testing framework then you should be - you can find more information here.--> Click here to continue on to look at some of the Metrics available at Class Level
<-- Click here to go back to the overview
If you are interested in Java Metrics you might be interested in topics that we are publishing in our Sidebars papers. Just click on this line to have a look.