标签: code-metrics

我最近使用了NDepend,它为我的.net程序集和相关的pdbs提供了一个很好的报告.

我在报告中发现的最有趣的事情是抽象性与不稳定性图.我想要真正详细地理解这一点,我阅读他们的文档和在线metrices,但它只能在一定程度上有所帮助.

主要是我希望了解如何正确评估图形以及如何稳定地控制抽象性.

这里有一篇非常好的文章就这个问题进行了讨论,但除此之外我还需要更多的内容是"如何控制它？[稳定控制抽象]'

可能重复:
如何计算Visual Studio解决方案中的代码行？

如何在Visual Studio 2008 Professional SP1中显示代码度量标准窗口？我希望看到我的项目用于学校的总代码行数,我找不到它.

帮助文件说转到View-> Other Windows-> Code Metrics,但我无法使用此选项.我还尝试在解决方案资源管理器中右键单击项目以查看是否有选项,但没有.

这个神秘的独角兽在哪里？如果Pro版本没有这个功能,有没有人找到一个简单的外部方法来自动计算所有.cs文件中的行？

我们正在记录我们的软件开发过程.对于技术人员来说,这非常简单:每四周内部里程碑进行迭代开发,每3个月外部一次.

但是,本练习的目的是以他们能够理解的方式为我们的项目管理公开事物.具体而言,这些非技术管理人员需要他们能够理解的指标.

我很了解我们的指标选择,并提出了一整套(满足要求,实际成本与预算成本是我最喜欢的两个).但是,我们确实有一些老手涉及,他们倾向于挂在像SLOC这样的指标上.

我理解SLOC的诱惑:非软件人员似乎很容易理解,这似乎是物理事物中最接近的类比(就像过去计算打孔卡片一样!).

所以这就是问题:如何向非技术人员解释SLOC的危险性？

这里有一些具体的动机:我们致力于一个相当成熟的部署系统,该系统背后有多年的历史.随着我们添加功能,SLOC趋于保持大致水平甚至降低(重构删除旧/死代码,新功能实际上只是对现有功能进行调整等).对于非程序员经理来说,开发项目中不增加的SLOC充其量只是令人困惑....

澄清以下最近的答案:记住,我认为SLOC对于衡量项目进展的目的而言是一个糟糕的指标.我并不是说这是一个不值得收集的数字.它需要广泛的上下文来做任何有用的事情,大多数程序经理都没有这种上下文.

在我的项目上运行声纳分析后,我在7个轴之一(见第二张图片)上有以下数据.可以从这些数据中解码哪些信息？此图中的哪些轴与此数据有关？

Hudson/Jenkins的源代码指标是否有任何有用的插件？

我正在寻找代码总数,测试总数,类和图表等.

有这样的事吗？

代码覆盖率可能是最具争议的代码度量标准.有人说,你必须达到80%的代码覆盖率,其他人说,它是肤浅的,并没有说明你的测试质量.(请参阅Jon Limjap关于"单元测试的合理代码覆盖率%(及其原因)是什么？"的完美答案.)

人们倾向于衡量一切.他们需要比较,基准等.
项目团队需要一个指针,他们的测试有多好.

那么什么是代码覆盖的替代品？什么是一个好的指标,而不是"我触及这行代码"？
有真正的替代品吗？

如果有人能够根据Visual Studio的Code Metrics规则向我解释以下两段代码之间的区别,我将不胜感激.如果我不将所有内容封装在内,为什么可维护性指数会略有增加using ( )？

样本1(MI分数为71)

public static String Sha1(String plainText)
{
    using (SHA1Managed sha1 = new SHA1Managed())
    {
        Byte[] text = Encoding.Unicode.GetBytes(plainText);
        Byte[] hashBytes = sha1.ComputeHash(text);
        return Convert.ToBase64String(hashBytes);    
    }
}

样本2(MI分数为73)

public static String Sha1(String plainText)
{
    Byte[] text, hashBytes;
    using (SHA1Managed sha1 = new SHA1Managed())
    {
        text = Encoding.Unicode.GetBytes(plainText);
        hashBytes = sha1.ComputeHash(text);
    }
    return Convert.ToBase64String(hashBytes);   
}

我理解指标在更广泛的背景和理解之外是没有意义的,程序员应该行使自由裁量权.虽然我可以将分数提高到76 return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))),但我不应该.我显然只是在玩数字,而且在那一点上它并不是真正的可读性或可维护性.我很好奇这个案例增加背后的逻辑是什么.这显然不是行数.

我们一直在寻找测量TypeScript代码质量的好工具.主要是,我们感兴趣的是测量Cyclomatic Complexity,LCOM,不稳定性和类似指标.用于可视化模块之间的依赖关系的工具也很不错.

一种"NDepend for typescript"会很棒 - 但是我们找不到类似的东西......

有人能指出我们提供某些此类功能的工具的方向吗？

虽然LOC(#行代码)是对代码复杂性的有问题的衡量,但它是最受欢迎的,并且在非常仔细地使用时,可以提供对代码库的至少相对复杂性的粗略估计(即,如果一个程序是10KLOC)另一个是100KLOC,用相同的语言编写,由大致相同能力的团队编写,第二个程序几乎肯定要复杂得多).

在计算代码行时,您是否更愿意计算注释？测试怎么样？

我见过各种方法.像cloc和sloccount这样的工具允许包含或排除注释.其他人认为评论是代码的一部分及其复杂性.

单元测试存在同样的困境,有时可以达到测试代码本身的大小,甚至超过它.

我已经看到了整个范围内的方法,从仅计算"操作"非注释非空白行到"XXX行测试,注释代码",这更像是在所有代码文件中运行"wc -l"项目".

您的个人偏好是什么？为什么？

虽然过时和痛苦 - 我在一家公司工作,继续积极使用VB6进行大型项目.实际上,18个月前我们遇到了32k标识符限制.

不愿意放弃大型代码库并重写.NET中的所有内容,我们将应用程序分解为主可执行文件和几个支持DLL文件.本周我们又遇到了32k的限制.

我们遇到的问题是,我们找不到的任何工具都会告诉我们我们的源使用了多少个唯一标识符.我们没有准确的方法来衡量我们的努力如何减少标识符的数量或我们达到限制之前的接近程度.

有没有人知道一个工具会扫描项目的来源并返回一些准确的指标和统计数据？