What Passes For "Lines of Code"?
Author
When you tell someone you have 10,000 lines of code in your project, what gets counted as a "line"? white space? comments? Or perhaps i should ask: what does NOT get counted?
What do you say?
grep -r ''' * | wc -lI guess you can grep -v '^$' or something to get rid of blank lines, but really, it's a waste of time to worry about that. LOC is relatively unimportant. Why do you want to know? hehe.
Ususally you use a program like sloccount (http://www.dwheeler.com/sloccount/) to count the lines of code. I know that it doesn't count comments, at least.
Author
Quote:Original post by James Trotter
Ususally you use a program like sloccount (http://www.dwheeler.com/sloccount/) to count the lines of code. I know that it doesn't count comments, at least.
Cool, i missed that one. There was a Debian package and everything! Thanks.
sloccount says my engine project would cost $459,150 to produce.
Look, there goes my ego!
My definition for a "line" of code is a line that does something. Comments, formating, blank lines, { } does not count, it must be code that processes something.
theTroll
theTroll
I generally assume it means number of lines containing at least one non-whitespace, non-comment character.
But if you want a metric of code complexity that doesn't suck, look up Cyclomatic Complexity. Having said that, line counds and cyclomatic complexity are really useful for different things - code complexity should be minimized, since more complex code contains more bugs, cyclomatic complexity is useful for measuring the complexity of some relatively small section of code (eg, one function, or a few functions). Line counts only make sense on a much larger scale, to give a rough estimate of the scale of an entire project.
Another one that might be reasonable is object-code size, when compiled with optimization. Although it would only make sense to compare the sizes of things compiled with the same compiler and settings.
John B
But if you want a metric of code complexity that doesn't suck, look up Cyclomatic Complexity. Having said that, line counds and cyclomatic complexity are really useful for different things - code complexity should be minimized, since more complex code contains more bugs, cyclomatic complexity is useful for measuring the complexity of some relatively small section of code (eg, one function, or a few functions). Line counts only make sense on a much larger scale, to give a rough estimate of the scale of an entire project.
Another one that might be reasonable is object-code size, when compiled with optimization. Although it would only make sense to compare the sizes of things compiled with the same compiler and settings.
John B
I say it doesn't matter.
Two people could code the same function and each could have different line counts, speed not line counts matter.
Two people could code the same function and each could have different line counts, speed not line counts matter.
Any company which counts LOCs as a measure of productivity richly deserves the code it ends up with.
A coworker of mine told me that 20-40 years or so ago he had the Lines of code for performance, but it backfired. programmers would code the program with the largest footprint, but with the days of mainframes with limited resoruces the smaller programs were given a higher priority in the thread pool. So lines of code did not help in measure a good programmer from a bad one...
Plus I could write the same logic 2 different ways (and then some)
Wow... Example 2 is almost 3 times longer... so that programmer should get a raise that is 3x more than the first programmer.
Plus I could write the same logic 2 different ways (and then some)
for (int i = 0; i < len; i++){ cout << i << endl;}int i;for ( i = 0; i < len; i++){ cout << i << endl;}Wow... Example 2 is almost 3 times longer... so that programmer should get a raise that is 3x more than the first programmer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
