Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I'm dealing, again, with a messy C++ application, tons of classes with confusing names, objects have pointers into each other and all over, longwinded Boost and STL data types, etc. (Pause and consider your favorite terror of messy legacy code. We probably have it.) The phrase "code rot" oft comes to mind when I work on this project.

Is there a quantitative way to measure code rot? I wouldn't expect anything highly meaningful or scientific, since no other measure of code productivity or quality is so fine. I'm not looking for a mere opposite of measures of code quality, but specifically a measure of how many bad things happened after a series of maintenance software "engineers" have had turns hacking at the code.

A general measure applying to any language, or many languages, would be great. If there's no such thing, at least for C++, which is a better than average language for creating messes.

Maybe something involving a measure of topology of how objects connect during runtime, a count of chunks of commented out code, how mane files a typical variable's usage is scattered over, I don't know... but surely now, a decade into the 21st Century, someone has attempted to define some sort of rot measure.

It would be especially interesting to automate a series of svn checkouts, measure the "rottenosity" of each, and plot the decay over time.

share|improve this question

migrated from stackoverflow.com Feb 23 '11 at 5:18

This question came from our site for professional and enthusiast programmers.

marked as duplicate by gnat, MichaelT, GlenH7, Kilian Foth, Dan Pichelman Aug 26 '13 at 16:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

34  
The only scientific unit of measure for this is the OMGWTF/sec –  Robert Massaioli Feb 23 '11 at 3:39
    
@Robert, clever :) –  Marlon Feb 23 '11 at 4:00
1  
This might be better on programmers.stackexchange. –  templatetypedef Feb 23 '11 at 4:00
1  
I've always wanted to have expiry dates on code. When code hasn't has a review in one year, it needs to either stop compiling or give off a sulfer smell like a bad egg. –  smithco Feb 23 '11 at 6:00
1  
not an answer, but I call this issue the technical debt. Code do not rot by itself with time. Its quality decreases when work on it is done as quickly as possible without thinking about the guy who will end up maintaining the resulting mess. –  Simon Dec 22 '11 at 13:12
show 3 more comments

4 Answers

up vote 7 down vote accepted

This list has a whole bunch of metrics that can be used to measure one aspect or another of code rot.

McCabe IQ uses a vast number of software metrics to get the most precise assessment of your application's quality, security, and testing. We've defined these metrics below for your reference. Further details on many of these metrics can be found in the NIST document- "Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric" by Arthur Watson and Tom McCabe...

share|improve this answer
    
Consider using Sonar [sonarsource.org/] with it's C/C++ plugin to help measure these –  deterb Jan 3 '12 at 22:37
add comment

http://i.stack.imgur.com/ARBSs.jpg

Which door represents your code?...

...Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks? How can we make sure we wind up behind the right door when the going gets tough? (Robert "Uncle Bob" Martin, Clean Code: A Handbook of Agile Software Craftsmanship)


Any quality measure / metric is at risk of being useless unless backed by code reviews. In my experience I haven't yet seen a metric that was impossible to trick into 100%-perfect-digits garbage. On the other hand I can't recall a code review where I was able to trick reviewer (though have to admit I never tried it hard).

share|improve this answer
    
+2 for the picture. I'm stuck behind a "Bad Code" door at the moment. –  Dark Star1 Dec 22 '11 at 10:44
add comment

Cyclomatic Complexity Metric (one definition is here) is one metric used to measure the ugliness of code. Tools from companies like Coverity can measure the CCM of a set of code. I don't work for Coverity but have used the product for defect analysis (we don't pay much attention to the CCM).

The best answer to this question may be the

OMGWTF/sec

given earlier by Robert above.

share|improve this answer
add comment

Unit tests. Put in unit tests, and then watch them break when bad check-ins happen, that's the rot. Of course, once there are unit tests keeping them working prevents the rot.

share|improve this answer
3  
I'm not sure that's sufficient. What about huge piles of code that are no longer used? Just because the tests still work, it doesn't mean that the code isn't sitting there rotting. –  Gabe Feb 23 '11 at 4:08
2  
If it's unused, delete it! If it's "supposed to be used", add integration tests. –  Adam Vandenberg Feb 23 '11 at 4:16
2  
Problem is, the usual legacy code has no unit tests whatsoever. And is not unit testable either, because it was not designed for that. So you need to refactor to make it unit testable. Which already brings it to a much better shape. A prime example of the act of "observation" changing the very result you are trying to observe. –  Péter Török Feb 23 '11 at 9:44
2  
Unit tests won't tell you about the comments that don't match the code, variable names that don't describe what they do, functions that are no longer used, or all the special cases that are there just to pass unit tests. –  Gabe Feb 28 '11 at 1:12
1  
Code rot is not about stuff that doesn't work. It is about stuff that you can't understand or change. –  Stephen C Aug 25 '13 at 1:01
show 1 more comment

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