visual-studio 什么是使用 Visual Studio 2008 代码分析的良好可维护性指标？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/38158/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is a good maintainability index using Visual Studio 2008 code analysis?
提问by Toran Billups
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?
我的公司最近购买了 TFS，我开始研究代码分析工具以帮助提高代码质量，并注意到一个很好看的指标“可维护性指数”。是否有人使用此指标进行代码/签入/等？如果是这样，开发人员可以接受的指标是什么？
回答by Erik van Brakel
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.
可维护性指数并不是您所看到的固定值，它更多地表明代码难以理解、测试和/或调试。我通常会尝试将高级代码（基本上除了真正的管道代码之外的任何代码）保持在 80 以上，其中 90+ 会很好。它为我尽可能可维护的编程添加了竞争元素。
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.
最后，我认为这主要取决于您的代码更改的频率。与典型的“一次编写”代码相比，预计会发生大量变化的代码在可维护性方面的得分必须更高。
