File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes metrics Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "metrics" Watch "metrics" New topic


Lucky Singh
Ranch Hand

Joined: Jan 19, 2004
Posts: 125
where can i find tools to measure metrics like LOC, etc for Java? I would also like the source code. Is there any site where I can get the source code and the tool?
Jeff Langr
Ranch Hand

Joined: May 14, 2003
Posts: 799

Not much value in NCSS other than a rough idea of how the code is expanding. Run it every couple of weeks, and be alarmed when you have out-of-the-ordinary growth. Otherwise, it provides a nice meaningless number that executives might find useful.


Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
as Jeff says, LOC count is useless and often counterproductive.
It actively dissuades people from writing reusable objects and from refactoring for more terse code.

An example from the trenches.
Major company, their largest project (70 people fulltime, budget in the tens of millions of dollars a year).
The most sacred productivity measurement was KLOC count (that's thousands of LOC) with strict minimums being set for each team of programmers for each release cycle.
My team was tasked for one release with cleaning up a lot of dead code and fixing Y2K bugs (the 2 were closely related of course).
As a result we ended up with hardly any new code (maybe a few thousand lines) but we did manage to remove literally tens of thousands of lines of code from the codebase which we managed as a team which was several million lines.
End result was that for that release our KLOC count was some 25000 lines of code negative, and we were officially reprimanded for not reaching our goals...
Had we simply left all that dead code in and replaced all the faulty modules with entirely new ones having the same functionality except for using 4 digit years we'd have ended up with a KLOC count well over our target and been praised.

Other example:
A team under KLOC pressure has to write some new code.
That code has a lot of generic functionality in it, in a lot of places there's handling of amounts of money and dates.
Seems an ideal area to create some reusable objects and just call those.
Problem is that that will reduce the amount of code produced, threatening the KLOC goals. So each module gets its own functions for handling those amounts and dates, usually copied verbatim from somewhere else, just to shore up the volume of code produced.

I've been involved in the first example myself, and seen the second happen more often than I care to remember.

I agree. Here's the link:
subject: metrics
It's not a secret anymore!