This may be a good statistic for the specific case of refactoring, but "Lines of Code" actually mean nothing except as an approximate measure for the amount of work done in a piece of code. [1][2]
And as Charles Babbage will helpfully tell you: garbage in, garbage out. [3] This may be a useful estimate at one time or another, but posting this on a wall harkens back to the old practice of managers measuring LoC to identify best-performing employees. (And as we learned, it didn't work. [4])
Actually, I think that unlike "total LoC in project" "LoC in function" might be a useful measure, since this it frequently measured against "How many LoC can I fit on my screen?" Also, this method isn't using absolute LoC as a measure of anything, and isn't trying to measure the amount of work being done. It's looking at how often the LoC in a function increases and decreases in order to identify a specific feature that might be indicative of problematic code bases: functions that grow monotonically over time. I think it's a good assumption that, for a given function function, change in LoC is positively correlated with change in complexity.
I agree that LOC is a lousy productivity measure but I think think it could be decent health measure.
The distribution of method line counts looks like it's a power law. In code bases I've looked at there are way more methods with one or two lines - the distribution tapers down to the couple of large methods we all have in our code. My guess is that the coefficients of the distribution tell us something about health. I've seen some very good code with distributions that taper down very quickly.
No, I really think you have to separate LOC as a productivity metric from these other uses.
4 comments
[ 3.3 ms ] story [ 22.5 ms ] threadAnd as Charles Babbage will helpfully tell you: garbage in, garbage out. [3] This may be a useful estimate at one time or another, but posting this on a wall harkens back to the old practice of managers measuring LoC to identify best-performing employees. (And as we learned, it didn't work. [4])
[1]: http://www.callingshotgun.net/geekery/lines-of-code-dispelli... (admittedly over the top /me shrugs)
[2]: http://www.imdb.com/title/tt0107290/quotes?item=qt1546480
[3]: https://en.wikipedia.org/wiki/Garbage_in,_garbage_out#Histor...
[4]: Those who cannot remember the past are condemned to repeat it. (from https://en.wikiquote.org/wiki/George_Santayana)
The distribution of method line counts looks like it's a power law. In code bases I've looked at there are way more methods with one or two lines - the distribution tapers down to the couple of large methods we all have in our code. My guess is that the coefficients of the distribution tell us something about health. I've seen some very good code with distributions that taper down very quickly.
No, I really think you have to separate LOC as a productivity metric from these other uses.