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

在计算代码行时,您是否希望在中计算注释?那测试呢?

我已经看到了各种方法。诸如cloc和sloccount之类的工具允许包含或排除注释。其他人认为注释是代码及其复杂性的一部分。

单元测试也存在同样的难题,有时可能会达到测试代码本身的大小,甚至会超过它。

我看到了遍及整个领域的方法,从仅计算“可操作的”非注释非空白行到“ XXX行的经过测试的,带注释的代码”,这更像是在运行中的所有代码文件上运行“ wc -l”项目”。

您的个人喜好是什么?为什么?

最佳答案

一位聪明的人曾经告诉我,在管理程序员时,“您得到了所要衡量的”。

如果您在它们的LOC输出中对它们进行评分,那么您往往会得到很多行代码。

如果按关闭的错误数量对它们进行评分,那么令人惊讶的是,您会修复很多错误。

如果按添加的功能对它们进行评分,则会得到很多功能。

如果对圈复杂度进行评分,您会得到非常简单的功能。

由于这些天代码库的主要问题之一是它们增长的速度以及增长后如何难以改变,因此我倾向于完全避免使用LOC作为度量标准,因为它会导致错误的基本行为。

就是说,如果您必须使用它,请计算无注释和测试内容,并需要一致的编码风格。

但是,如果您真的想要度量“代码大小”,则只需tar.gz代码库即可。它比计数行容易更好地粗略估计“内容”,因为行数易受不同编程风格的影响。

07-24 09:52
查看更多