• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
  • Carey Brown
  • Tim Holloway
  • Joe Ess

metrics  RSS feed

Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
Ranch Hand
Posts: 799
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!