指标和面向对象的程序设计 [英] Metrics & Object-oriented programming

问题描述

我想知道是否有人经常使用度量来验证其代码/设计. 例如，我想我将使用:

I would like to know if somebody often uses metrics to validate its code/design. As example, I think I will use:

• 每种方法的行数(<20)
• 每种方法的变量数(<7)
• 每种方法的参数数量(<8)
• 每个类的方法数量(<20)
• 每个类别的字段数(<20)
• 继承树的深度(<6).
• 方法缺乏凝聚力

这些指标大多数都很简单.

Most of these metrics are very simple.

您对这种保证有何政策?您是否使用工具来检查其(例如NDepend)?

What is your policy about this kind of mesure ? Do you use a tool to check their (e.g. NDepend) ?

推荐答案

我在您的列表中没有看到的指标是McCabe的Cyclomatic Complexity.它测量给定功能的复杂性，并且与错误有关.例如.函数的高复杂度评分表明:1)可能有错误的功能是 ，2)难以正确修复的可能是 (例如，修复会引入它们的缺陷自己的错误).

A metric I didn't see in your list is McCabe's Cyclomatic Complexity. It measures the complexity of a given function, and has a correlation with bugginess. E.g. high complexity scores for a function indicate: 1) It is likely to be a buggy function and 2) It is likely to be hard to fix properly (e.g. fixes will introduce their own bugs).

最终，最好在总水平上使用指标-像控制图一样.您要寻找控制极限以上和以下的点以识别 特殊情况，然后查看详细信息.例如，具有很高的圈复杂度的函数可能会导致您查看它，却发现它是适当的，因为它是在许多情况下的分派器方法.

Ultimately, metrics are best used at a gross level -- like control charts. You look for points above and below the control limits to identify likely special cases, then you look at the details. For example a function with a high cyclomatic complexity may cause you to look at it, only to discover that it is appropriate because it a dispatcher method with a number of cases.

这篇关于指标和面向对象的程序设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！