Are there any open source tools to calculate Halstead Complexity metrics for Java source files.
Asked
Active
Viewed 1.1k times
3
-
I am not sure Halstead metrics as defined in the original paper are well suited for Java. – Gabriel Ščerbák Feb 01 '11 at 20:18
-
@Gabriel Any specific reason why you say this? I am working on a tool that does some statistical analysis of "Code" using Halstead, Cycomatic and some other LoC metrics. I am looking for some command line utilities that can give me Halstead & Cyclomatic metrics for programing languages. Truly I have not looked into specifics of which one is good for which language. Any help is much appreciated. Thanks. – Salman A. Kagzi Feb 06 '11 at 17:28
-
@Salman: Halstead metrics are based on number of operators and operands. It is quite hard to count that in language like Java, which is not procedural but object oriented. Take for example the volume metric, I suppose that is interesting for you, it basically says, that programs grow linearly with their lenght and logarithmically with its vocabulary. But in object oriented programming I guess it depends quite much if a method (operator) is something new or an implementation of interface or overriden method. E.g. adding new collection interface is very different than adding new implementation. – Gabriel Ščerbák Feb 06 '11 at 22:10
-
@Gabriel: and why are method calls fundamentally different than procedure calls? What Halstead measures is the complexity of the computation as expressed. It doesn't care what the internal complexity of any particular operator is (whether "*" or "foobar(...)"). – Ira Baxter Mar 31 '11 at 20:46
-
@Ira Baxter Halstead metrics try to measure perceived complexity of source code, not the actual complexity of the computation as for example big-O complexity. The difference is as I wrote above that when you see call of get(i) on a List implementation it is perceived different as a call of get(i) on class you know nothing about. Interfaces (and classes) create contracts, which allow you to ignore details, but still know about some features of the behaviour. This is fundamental for OOP. Halstead metrics ignore that. – Gabriel Ščerbák Apr 01 '11 at 06:11
-
@Gabriel: Why is a method call any different in concept than a plain function call from the point of view of Halstead? It does some abstract operation, just like "*" and "SELECT FROM". These are just "operations", and they have (implicit) contracts, too. If you believe Halstead metrics can measure procedural code, I don't see how you can believe it cannot measure OO code. Are you quoting something from Halstead's papers? – Ira Baxter Apr 01 '11 at 06:55
-
@Ira Baxter: No, I am not quoting, I only read some discussion regarding Halstead metrics for OO design. The problem is not that you cannot measure it that way, but that the results are not so accurate. Halstead metrics make no difference between operator names such as `isEquivalentTo` and `Object.equals`, but in Java you know that any implementation of `Object.equals` has to be reflective, symetric and transitive - about `isEquivalentTo` you know nothing before looking at implementation. – Gabriel Ščerbák Apr 01 '11 at 13:25
-
@Gabriel: Halstead doesn't measure what you know about operators; it is independent of the agent viewing the code. If it did, it would produce different measurements for newbies than it did for experts. The assumption behind counting operators is pretty simple: if one program has more operators than another, it is likely harder to understand. Ultimate the reader of the reader of the code has to understand all the operators in it, whether they be "built in" or whether they be some function in some API somebody wrote. I guess I don't believe the people who were "discussing this". – Ira Baxter Apr 01 '11 at 13:47
-
@Gabriel: can you point to a refereed technical paper in which the point you are defending was made? A discussion in an email forum isn't very convincing if that's what it was (including my comments :). For what it's worth, no simple metric (Halstead or any other) is "so accurate"; they are trying to estimate complexity of understanding/modifying using some other substitute. I'll be the first to agree that counting "+" (add) and "fft(...)" both as one unit severely distorts the real cost of understanding "+" vs "fft". But Halstead is simply trying to approximate complexity – Ira Baxter Apr 01 '11 at 13:54
-
@Ira Baxter: I looked in my notes and found the same site as mentioned in the answer to this question. Towards the end of the article authors mention that it is pretty complicated to define Halstead metrics beyond the method level, their argument is based on problems with counting instance variables as operands. I might have extended this issue from object to inter-class scope. – Gabriel Ščerbák Apr 01 '11 at 19:53
-
@Ira Baxter: Apart from that I found this nice paper: `http://www.rafa-elayyan.ca/publications/IWSM-2005.pdf` which states that there hasn't been agreement even on what are operators and what operands, there are references to differnt definitions and to paper which proposes special counting strategy for OOP. – Gabriel Ščerbák Apr 01 '11 at 19:54
-
@Gabriel: You'll find that kind of argument everywhere in the metrics world. Everybody agrees "statementcount" is some kind of useful metric. Try to get a clear definition of "statement". The real issue here is that you can get caught up in the nanoscopic details but all that will do is produce a lot of heat. What you really want is *some* kind of indicator that correlates in a more or less positive way with the actual effort to understand the code, so that you can tell what code might be harder to work with and adjust your expectations on resources and schedules accordingly. – Ira Baxter Apr 01 '11 at 21:04
-
@Gabriel: This is entertaining: http://stackoverflow.com/questions/2349916/is-there-a-standard-way-to-count-statements-in-c – Ira Baxter Apr 01 '11 at 21:13
-
@Gabriel: The real problem is that all metrics are counting some kind of surface property of the code to get some sense of the how hard the code is to handle by the human brain. Given what we know about human brains (and indeed the gigantic difference in performance between them ["Do Not Use This Brain" is pretty famous]), the fact that metrics produce anything useful at all is pretty amazing. Ideally what you want is some excruciatingly defined metric validated by a deep, long test on lots of real world programmers. You aren't going to get that. Best to take them with a grain of salt. – Ira Baxter Apr 01 '11 at 21:15
-
@Ira Baxter: True. But if you try to be too macroscopic, you will end up with good old LOC, which correlates with pretty much every metric:). I looked at some metrics for OO design and I prefer those which try to be OO specific. Halstead is nice for methods, but I think for OO it is as good as cyclomatic complexity, it is very local scoped metric. – Gabriel Ščerbák Apr 02 '11 at 01:23
-
@Gabriel - if Halstead is nice for methods (just as cyclomatic complexity is), then it is also good for OO development. After all, you still have to manage the internal quality of your methods (and people do write horrid methods within classes.) I tend to assign cyclometic complexities and packages as the average of individual measure of methods within that class or package at build time. That (in combination with LCOM) gives a good 10K foot view red-flagging any potential structural problems before they grow out of hand. Never done with halstead, but should be equally good. – luis.espinal Jul 13 '11 at 14:46
-
@luis.espinal out of curiosity, which of LCOMs do you use? – Gabriel Ščerbák Jul 13 '11 at 20:05
-
1@Gabriel - at work we use a commercial tool that uses LCOM2. I would have preferred to use LCOM3 or LCOM4 (plus this tool red-flags POJOs unnecessarily.) However, in general, LCOM2 does the job to steer cohesion in the right direction. We also use in combination with CBO and a modified cyclomatic complexity measure that treats a n-case switch statements as a count of '1' (instead of 'n'). – luis.espinal Jul 17 '11 at 14:20
2 Answers
2
I was not aware of any open source tool that computes the Halstead metric for Java, but a quick look at Google code search turned up Prest. Obviously, I can't say anything about how good this software is since I only just discovered it.
There is an interesting discussion about the Halstead metric and Java at http://www.virtualmachinery.com/sidebar2.htm.
kc2001
- 5,008
- 4
- 51
- 92
