[p4] lines of code counting tools - Richard Brooksby - com.perforce.perforce-user

14 messages in com.perforce.perforce-user[p4] lines of code counting tools

From	Sent On	Attachments
Dave Lewis	16 Aug 2004 15:02
Vinny Murphy	16 Aug 2004 15:18
Dave Lewis	16 Aug 2004 15:23
David Surber	16 Aug 2004 15:40
David Surber	16 Aug 2004 16:45
Vinny Murphy	16 Aug 2004 16:56
David Surber	16 Aug 2004 17:58
Nick Barnes	17 Aug 2004 01:34
Richard Brooksby	17 Aug 2004 07:26
Janulewicz, Matthew	17 Aug 2004 09:45
Richard Brooksby	17 Aug 2004 10:47
Dave Lewis	17 Aug 2004 10:50
David Surber	17 Aug 2004 11:03
ste...@vance.com	17 Aug 2004 12:37

Subject:	[p4] lines of code counting tools
From:	Richard Brooksby (rb...@ravenbrook.com)
Date:	08/17/2004 10:47:16 AM
List:	com.perforce.perforce-user

On 17 Aug 2004, at 17:46, Janulewicz, Matthew wrote:

At the risk of coming off like a jerk (which I've done before, thanks) I was wondering, in a more philosophical sense, what this data would be used for, anyway? Is the number of lines of code changed really a good matrix for anything? ...

For large enough projects the number of lines of code added or changed correlates well with the number of defects introduced, and can then tell you how much time and money you're going to have to spend on rework. You can also use a model like SMERFS (google for it) to give you some idea when you'll be ready to deliver something reliable. "Large enough" is pretty large, though. I wouldn't try it for less than a million line project with several hundred developers. And in any case you have to check the predictions against the reality and use that as feedback, so the whole system can take a year or more to settle.

... I was asked to provide total lines of code counts, over time, for some projects once and the managers quickly realized that the data didn't really tell them anything. They eventually became more interested in the quality of the code (code reviews), how long it took to fix particular defects, whether or not code had to be re-written, etc.

I bet they were also interested in accurate prediction of delivery times and rework costs. But in a small enough project you can just focus on code quality and everything else comes out in the wash. I've done that for a six-person project in the past and it worked very well.

That being said, a decent (I'm only halfway decent) shell scripter (unix or cygwin) could whip up a short script to parse 'p4 changes' into 'p4 describe', grep the pertinent results to a file, then use the built-in 'wc' command to count the lines. It shouldn't be that complicated, as perforce does most of the work (through describe') for you.

That'd be fine for a small system, in which the line counts are probably not useful (as you point out) ;-)