Re^3: Source lines of code (SLOC) -- meaningful number?

No.

First pass at the code tends to take time according to the number of function points. A line of perl code that I fully understand before I write it takes the same amount of time to think about as the 30 to 40 lines of assembler code it is equivalent to, with which I'm equally familiar. Typing the assembler code takes a bit longer, but they're pretty short lines and keyboard-memory takes over, so back when I was writing the assembler it would probably take me only 5 times as long to write the 30-40 lines of code as it does now to write 1 line of perl code.

Other features can also have a massive effect - when I started writing that assembler application, the assembler itself was hardwired to print out a full listing and concordance, and for the application I was dealing with that took about 7 hours. Since at that point we were just starting to get hold of hard disks, modifying the assembler to spool the listing to disk reduced the turnaround to around 5 minutes, which had a massive effect on how you could go about writing and debugging programs.

Similarly, how long it takes to find and fix a bug is in my experience much less dependent on LOC or language, and much more on the problem domain and the tools and techniques available - only the passage of time allows me to look back without shuddering at a stack corruption bug I once had in a keyboard interrupt handler, which took over a month of full time work to resolve.

Hugo

Comment on Re^3: Source lines of code (SLOC) -- meaningful number?

Replies are listed 'Best First'.

Re^4: Source lines of code (SLOC) -- meaningful number?
by Anonymous Monk on Jun 09, 2005 at 15:35 UTC

not

I'd agree that debugging tools have a massive impact on debugging time: using the perl debugger saves me a lot of time, as does gdb. Setting breakpoints at suspicious places, and being able to narrow down flawed code by single stepping through functions that are misbehaving until I get to the broken code is a huge timesaver.

Yes, I can get the same results "by hand", using trace statements or the like, but it takes many more runs get the same results, and I have to keep tinkering with the code, fixing stupid syntax errors in my debug statements, and so forth.

And on some systems, the core dump file you get isn't compatible with your debugger, so you either need to read it by hand (ick!), or run the whole program through the debugger for a while, and wait for it to die, so you can check the stack trace...yuck!

A good debugging environment is wonderful. A test suite that includes comprehensive regression tests is even better.

Lines of code give me a rough estimate of how much work is in the project, and how much can go wrong if I assume it's all a tangled mess just waiting to fall apart. It's a starting point for estimates of how long it will take to maintain code, assuming that the code is riddled with ridiculous side effects that shouldn't be in there, but are anyway. All too often, this assumption will turn out to be correct.

-- AC

[reply]


P is for Practical
	PerlMonks