Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
My company recently purchased TFS and I have started looking into the code analysis tools to help drive up code quality and noticed a good looking metric ‘maintainability index’. Is anyone using this metric for code reviews/checkins/etc? If so, what is an acceptable index for developers to work toward?
The maintainability index is not as much a fixed value you look at, it’s more of an indication that code is hard to understand, test and/or debug. I usually try to keep high-level code (basically anything except for the real plumbing code) above 80, where 90+ would be good. It adds a competitive element to programming as maintainable as possible to me.
The code analysis tool really shines in the area of dependencies and the number of branches within a method though. More branches mean harder testing, which makes it more error-prone. Dependencies, same thing.
In other people’s code, I use the maintainability index to spot possible bad parts in the code, so I know where to review it. Also, methods/classes with a high number of lines are an indication of poor code to me (unless it can’t be avoided, again, the plumbing works).
In the end, I think it mainly depends on how often your code will change. Code that’s expected to change a lot has to score higher in maintainability than your typical ‘write once’ code.