I think "n code changes before mandatory refactoring" might be a better idea, because untouched code doesn't tend to get worse. Updating the copyright date should be counted as a code change, too, so there's an implicit expiry date. Depending on your requirements, n can be a function based on the complexity of the code (the more complex, the fewer changes there should be before taking the time to refactor it).
It depends on your requirements. A good starting value would be 5 changes to a function of normal cyclomatic complexity (5); whereas a higher complexity should allow for less changes before refactoring.
In this case, n = (5 changes * 5 average complexity) / cyclomatic complexity of function/file.
If you find out that you want to be more averse to higher complexity, you could also square the complexity: n = (5 changes * (5 average complexity)² / (cyclomatic complexity of function/file)².
I think "n code changes before mandatory refactoring" might be a better idea, because untouched code doesn't tend to get worse. Updating the copyright date should be counted as a code change, too, so there's an implicit expiry date. Depending on your requirements, n can be a function based on the complexity of the code (the more complex, the fewer changes there should be before taking the time to refactor it).
I like your idea, just not sure how to define n.
Thank you for your contribution to the discussion.
It depends on your requirements. A good starting value would be 5 changes to a function of normal cyclomatic complexity (5); whereas a higher complexity should allow for less changes before refactoring.
In this case, n = (5 changes * 5 average complexity) / cyclomatic complexity of function/file.
If you find out that you want to be more averse to higher complexity, you could also square the complexity: n = (5 changes * (5 average complexity)² / (cyclomatic complexity of function/file)².
Very cool, don't leave this in a comment, I encourage you to post about this if you haven't already.