有些人声称代码最大的敌人是它的大小,我倾向于同意.然而,每天你都会听到类似的事情
问题:"#lines of code"何时有用？
ps:请注意,在做出这样的陈述时,语气"越多越好".
war*_*ren 105
我会说当你删除代码以使项目运行得更好时.
说你删除"X行数"令人印象深刻.并且比添加代码行更有帮助.
Jes*_*erE 46
我很惊讶没人提到Dijkstra的名言,所以这里有:
我今天的观点是,如果我们希望计算代码行数,我们不应该将它们视为"产生的线条"而应视为"花费的线条":当前的传统智慧是如此愚蠢以至于指出错误的一面.总帐.
引用来自一篇名为" 关于真正教授计算科学的残酷 "的文章.
Mar*_*sey 35
这是一个糟糕的指标,但正如其他人所指出的那样,它可以让您(非常)粗略地了解系统的整体复杂性.如果您要比较两个项目,A和B,A是10,000行代码,B是20,000,这并不能说明多少 - 项目B可能过于冗长,或者A可能是超级压缩的.
另一方面,如果一个项目是10,000行代码,另一个是1,000,000行,那么第二个项目通常要复杂得多.
当该指标用于评估某个项目的生产率或贡献水平时,会出现此问题的问题.如果程序员"X"将行数写为程序员"Y"的2倍,他可能会或可能不会贡献更多 - 也许"Y"正在解决一个更难的问题......
dod*_*der 17
当我发现它非常宝贵时,有一个特例.当你在面试时他们告诉你,你的部分工作将是维护现有的C++/Perl/Java /等.遗产项目.向面试官询问遗留项目中涉及多少KLOC(大约)会让您更好地了解您是否想要他们的工作.
像大多数指标一样,没有上下文,它们意味着很少.所以简短的回答是:从来没有(除了行式打印机,这很有趣!这些天谁打印出程序？)
一个例子:
想象一下,您正在对遗留代码进行单元测试和重构.它开始时有50,000行代码(50 KLOC)和1,000个可证明的错误(单元测试失败).该比率为1K/50KLOC =每50行代码1个错误.显然这是可怕的代码!
现在,经过几次迭代,您已经将已知的错误减少了一半(并且未知的错误超过最可能的错误),并且通过示例性重构将代码库减少了五倍.该比率现在为每20行代码500/10000 = 1个错误.这显然更糟糕!
根据您要制作的展示次数,可以将其显示为以下一项或多项:
所有的这些都是真的(假设我没有搞砸数学),他们都吸在总结,这样的重构工作,必须已经实现了巨大的进步.
用25年前我读过的一句话来解释,
"使用代码行作为度量标准的问题是它衡量解决方案的复杂性,而不是问题的复杂性".
我相信引用来自David Parnas在ACM杂志的一篇文章中.
有很多不同的软件指标。代码行是最常用的，也是最容易理解的。
我很惊讶代码行度量与其他度量相关的频率。我没有购买可以计算圈复杂度的工具来发现代码异味，我只是寻找行数多的方法，而且它们往往也具有很高的复杂度。
使用代码行的一个很好的例子是度量：每行代码的错误数。它可以让您直观地了解应该在项目中发现多少错误。在我的组织中，我们通常每 1000 行代码大约有 20 个错误。这意味着，如果我们准备发布具有 100,000 行代码的产品，并且我们的错误数据库显示我们发现了 50 个错误，那么我们可能应该进行更多测试。如果我们每 1000 行代码有 20 个错误，那么我们可能接近通常的质量。
一个不好的使用例子是衡量开发人员的生产力。如果您通过代码行来衡量开发人员的生产力，那么人们倾向于使用更多的代码行来交付更少的代码。
| 归档时间： |
|
| 查看次数： |
26602 次 |
| 最近记录： |