如何解释代码指标（由 SourceMonitor 计算）
阅读问题 "Calculate Code Metrics" 的答案后，我安装了工具 SourceMonitor 并计算了一些指标。
但我不知道如何解释它们。
”指标的“好”值是多少
- “分支语句百分比”
- “每个类的方法
- ” “每个方法的平均语句”
- “最大方法或函数 复杂性”
我在文档中没有找到任何提示，有人可以帮助我吗？
After reading the answers to the question "Calculate Code Metrics" I installed the tool SourceMonitor and calculated some metrics.
But I have no idea how to interpret them.
What's a "good" value for the metric
- "Percent Branch Statements"
- "Methods per Class"
- "Average Statements per Method"
- "Maximum Method or Function
Complexity"
I found no hints in the documentation, can anybody help me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SourceMonitor 是一个很棒的工具。
“每个类的方法”对于那些希望确保其类遵循良好的 OO 原则的人很有用（太多的方法表明类可能承担超出应有的任务）。
“每个方法的平均语句”对于大致了解每个方法的大小很有用。 对我来说更有用的是有关具有太多语句的方法的信息（双击模块以获得更细粒度的详细信息）。
函数复杂度对于确定代码有多糟糕很有用。 确实，我使用这些信息比其他任何东西都多。 这是关于模块中最糟糕的函数有多复杂的信息（至少根据圈复杂度）。 如果双击模块/文件，您可以找出哪个特定方法如此糟糕。
SourceMonitor is an awesome tool.
"Methods Per Class" is useful to those who wish to ensure their classes follow good OO principles (too many methods indicates that a class could be taking on more than it should).
"Average Statements per Method" is useful for a general feel of how big each method is. More useful to me is the info on the methods with too many statements (double click on the module for finer grain detail).
Function Complexity is useful for ascertaining how nasty the code is. Truly I use this info more than anything else. This is info on how complicated the nastiest function in a module is (at least according to cyclomatic complexity). If you double click on the module / file you can find out which particular method is so bad.
根据一般经验法则，圈复杂度应为 10 或更低。 在大多数情况下，从 11 到 20 的 CC 大约是您想要获得的最高值：一旦您达到 20 以上，您就更有可能遇到查找和修复缺陷的问题，而一旦您达到 50 以上，您通常会寻找现在需要重构的方法。
请记住，这些只是指导方针。 可以有一种 CC 为 25 的尽可能简化的方法； 当您需要更新这些方法时，您需要更加小心。
As a general rule of thumb, a cyclomatic complexity of 10 or less is where you want to be. A CC from 11 to 20 is about as high as you want to get in most cases: once you get above 20, you're more likely to encounter problems finding and fixing defects, and once you get above 50, you're usually looking at a method that needs to be refactored now.
Keep in mind that these are guidelines. It is possible to have a method with a CC of 25 that is as simplified as you can get it; you'll just want to be more careful with these methods when you need to update them.