What would be the best way to count lines of code from Java classes excluding comments and blank lines.
A:
Search for software metric for Java I am pretty sure you can find something. LOC is the metric for line of code
mathk
2010-06-09 19:36:45
+3
A:
See JavaNCSS. Also be aware that LoC is a worthless "metric".
I will now make a blatant appeal to authority by citing Dijkstra:
The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
— EWD, On the cruelty of really teaching computing science
UPDATE: If you're doing this as a practice exercise, then you should probably be using a parser and counting the actual statements.
Hank Gay
2010-06-09 19:36:51
+1 for `LoC is a worthless "metric"`!
FrustratedWithFormsDesigner
2010-06-09 19:37:42
This is just for practice
Adnan
2010-06-09 19:37:51
I disagree. LOC is a very helpful metric when used correctly. I agree that measuring a programmers productivity via LOC is silly, for the same reasons you say so. However, using LOC to measure code base growth is very helpful. What if you had a team whose code base grew 50% during testing? These sort of metrics are definately useful... IMHO.
gnucom
2010-06-09 19:48:30
@Hank Gay: the logical fallacy you're doing is not an "appeal to authority" but a "strawman" for nowhere did the OP state that he wanted to measure "programmer productivity". Besides that, there are a **lot** of cases where LOC makes sense: for example when refactoring huge spaghetti mess, it is very useful to see, after the facts, how many **LESS* lines of code you have. And anyway even if saying *"I'm working on a 5000/10000 lines codebase"* doesn't mean much, I doubt that your 5K/10KLOC app can do what the 300KLOC the programmer next door is working on can do. Same for millionLOC, etc.
NoozNooz42
2010-06-09 19:53:59
Even to measure the growth of the code base, it's (almost?) hopelessly course. What would knowing that your actual logic and your tests consume roughly equal LoC actually tell you? Branch coverage is almost certainly more useful.
Hank Gay
2010-06-09 19:55:01
@NoozNooz42Re: Strawman -> I would posit that the *overwhelming* majority of cases where somebody is trying to get a LoC count boils down to some crude metric of "productivity", so it seems reasonable to assume the majority case.Re: refactoring -> Reducing LoC through refactoring: while satisfying, it's still not very informative. Golfing your code will probably reduce LoC, but it won't help maintainability.Re: amount of functionality -> If you start talking about multiple orders of magnitude difference, then you're *probably* right. There are probably better indicators, though.
Hank Gay
2010-06-09 20:04:19