Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm trying to figure out a way to analyze code longevity in open source projects: that is, how long a specific line of code is active and in use.

My current thinking is that a line of code's lifespan begins when it is first committed, and ends when one of the following occurs:

  • It's edited or deleted,
  • Excluded from builds,
  • No code within its build is maintained for some period of time (say, a year).

NOTE: As clarification on why an "edit" is being counted as "death", edited lines would be counted as a "new" generation, or line of code. Also, unless there's an easy way to do this, there would be no accounting for the longevity of a lineage, or descent from an ancestor.

What else would determine a line of code's lifespan?

share|improve this question

3 Answers 3

up vote 8 down vote accepted

Andy Ozment looked at OpenBSD in 2006 with the same sort of question: Milk or Wine: Does Software Security Improve with Age?

You may be able to learn from his definition. It's also a very interesting paper, with an interesting conclusion as well, one that hasn't been incorporated into software management lore:

Over a period of 7.5 years and fifteen releases, 62% of the 140 vulnerabilities reported in OpenBSD were foundational: present in the code at the beginning of the study.

It took more than two and a half years for the first half of these foundational vulnerabilities to be reported. We found that 61% of the source code in the final version studied is foundational: it remains unaltered from the initial version released 7.5 years earlier. The rate of reporting of foundational vulnerabilities in OpenBSD is thus likely to continue to greatly influence the overall rate of vulnerability reporting.

We also found statistically significant evidence that the rate of foundational vulnerability reports decreased during the study period. We utilized a reliability growth model to estimate that 67.6% of the vulnerabilities in the foundation version had been found. The model’s estimate of the expected number of foundational vulnerabilities reported per day decreased from 0.051 at the start of the study to 0.024.

share|improve this answer
+1 @Bruce Ediger: Awesome, thanks -- looking at it right now! – blunders Jun 8 '11 at 17:13
Again, thanks, so the only information I'm able to find of use is "We learn that 61% of the lines of code in today’s OpenBSD are foundational: they were introduced prior to the release of the initial version we studied and have not been altered since." - which while interesting, not really related. Everything else appears to focus on how long it takes vulnerabilities to be fixed, which again, interesting, but says nothing about factors to account for in code lifespan. Is there something I'm missing? – blunders Jun 8 '11 at 21:55

I don't think there is an answer for that. It's highly project dependant. Some are more stable over the years, others are more volatile/refactored/evolving over the years.

Moreover, it's difficult to measure. Is an editted line really the end of it's lifespan? What about only a cosmetic change like reformatting the codebase with tabs or spaces? IMHO that doesn't count as renewed codebase, but it would according to your criteria.

That said, I think a good chunk of the LOCs live forever.

The reason is simple: it's way easier to add new code rather than to remove some. Especially when the system is complex and grown over the years. It then quickly comes to a point where it's "risky" to remove or change non-trivial code. It could introduce bugs, break compatibility, introduce a butterfly effect of changes... So I think, the bigger the codebase becomes, the older it is, the more the LOCs are going to stay.

Moreover, only good programmers tend to cleanup codebases and reduce the lines. All others tend to pile up the LOCs. And so far, the latter are winning by far. ;)

share|improve this answer

would add 'when the line of code can no longer be executed' (dead code)

share|improve this answer
+1 @Steven A. Lowe: Yes, I'd thought about that, thought how would you know if the code was being executed? Clearly if it's not being executed within a build it's dead. Do you it's not within the controlflow's execution path? If you mean for example how WindowsXP is not in active development, but still in active use, not sure how you'd know if the code was, or not in active use, maybe downloads, though that's still not real executions. Thanks for the input! – blunders Jun 8 '11 at 17:12
The question of whether a given line of code can be or will be executed is equivalent to the Halting Problem, so there's no general algorithmic solution, which means it can't possibly be automated. – David Thornley Jun 8 '11 at 19:26
@David: modern compilers are quite good at this – Steven A. Lowe Jun 8 '11 at 19:34
@Steven A. Lowe: If you mean that they can find a lot of the code that isn't executed, sure. There's no way to find all of it unless you're willing to allow code that is executed to be misclassified, which usually isn't the case. – David Thornley Jun 8 '11 at 19:54
@David, @blunders: That is false. the .Net compiler will give you a warning for "Unreachable code detected". For example, if(false){foo();} will never execute foo(). – Morgan Herlocker Jun 8 '11 at 19:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.