SLOC(源代码行)作为度量有多糟糕?[关闭]

有人说:

“使用sloc测量软件进度就像使用kg测量飞机制造进度一样。”

这是完全不恰当的,因为它鼓励了诸如:

• 复制粘贴综合征

• 不鼓励重构以使事情更简单

• 用毫无意义的评论填充

• …

唯一的用途是,当您打印完整的源代码树时,它可以帮助您估计要在打印机中放入多少纸张。

SLOC的问题是它是一个很容易的衡量标准。生产并不等于生产更多的代码。所以,我向人们解释斯基尔德里克说的是:

1. 代码行越多,得到的东西就越复杂。
2. 事情越复杂,就越难理解。
3. 在添加新特性或修复bug之前,我需要理解它。
4. 理解需要时间。
5. 时间需要金钱。

更小的代码--更容易理解--添加新功能更便宜

bean计数器可以理解这一点。

向他们展示以下两者的区别:

for(int i = 0; i < 10; i++) {
    print i;
}

和

print 0;
print 1;
print 2;
...
print 9

问他们10个SLOC还是3个SLOC更好。

回应评论:

1. 很快就能解释 for 循环工作。

2. 在你给他们看了这个之后,说“我们现在需要打印多达100个数字——这是你如何进行更改的。”然后显示更改非干代码需要多长时间。

我不同意SLOC是一个糟糕的度量标准。用11个答案来回答一个有多年历史的问题可能是没有意义的,但我还是要补充一个。

大多数参数都将其称为糟糕的度量,因为它不适合直接度量 生产力 . 这是一个奇怪的论点;它假定度量标准被疯狂地使用。根据这种推理,人们可以称开尔文为一个坏单位,因为它不适合测量距离。

码长是一个可行的道碴测量方法。

非注释代码行的数量与以下内容相关:

• 未检测到的错误
• 维修费用
• 新贡献者的培训时间
• 迁移成本
• 新功能成本

还有许多类似的成本,比如优化成本。

当然,sloc计数并不是对这些数据的精确测量。代码可以在非常好和非常难看的地方进行管理。但可以假定代码长度很少是自由的,因此,较长的代码通常难以管理。

如果我管理一个程序员团队,我会非常想跟踪它创建或移除的压舱物。

说明sloc是应用程序中代码行的优秀度量, 没有别的了 .

一本书的行数或一部电影的长度不能决定它有多好。你可以改进和缩短胶卷,你可以改进应用程序和减少代码行。

相当糟糕(—:

更好的方法是覆盖测试用例,而不是代码。

其思想是:开发人员应该提交一个失败的测试用例,然后在下一个构建中提交修复,测试用例应该通过……只需测量开发人员添加了多少测试用例。

作为奖励,收集覆盖率统计(分支覆盖率比这里的行覆盖率更好)。

你不能根据一个平面的重量(sloc)来判断它有多好(有多少特性,如何执行…)。

当你想让你的飞机飞得更高、更长、性能更好的时候,你就不会给它增加重量。你用更轻/更好的材料替换它的部分。你把不需要的零件脱掉,以免增加不必要的重量。

我相信SLOC是一个很好的度量标准。它告诉你你的系统有多大。这有助于判断复杂性和资源。它帮助您准备下一个开发人员处理代码库。

但是,只有在应用了其他适当的代码质量度量之后,才应该分析SLOC计数。所以…

• 如果1可以,不要写2行代码,除非2行代码 版本使代码的维护容易两倍。
• 不要用不必要的注释来破坏代码,只会破坏sloc计数。
• 不要按Sloc计数付钱给人。

我已经管理软件项目30年了。我一直使用sloc count来帮助理解成熟的系统。在项目接近1.0版本之前,我从来没有发现浏览sloc计数是有用的。

基本上,在开发过程中,我担心质量、性能、可用性和规范的一致性。把这些做好,这个项目可能会成功。当尘埃落定时,看看sloc计数。你可能会惊讶于你从5000行代码中得到了这么多。你可能会惊讶你这么少!(但是SLOC计数不会影响质量、性能、可用性和规范的一致性。)

而且总是像下一个为你的代码工作的人一样,代码是一个暴力的精神病患者,他知道你住在哪里。

干杯, 奇普叔叔

即使是现代的代码度量工具也批评sloc conting,我喜欢projectcodemeter常见问题解答中的要点:

What's wrong with counting Lines Of Code (SLOC / LLOC)?

为什么sloc作为生产力的一个单独度量标准是不好的?

把代码想象成一块粘土/石头。你需要雕刻,比如10尊雕像。重要的不是你雕刻了多少雕像。重要的是你雕刻得有多好。同样的,不是你写了多少行,而是它们的功能有多好。在使用代码的情况下,loc可能会以这种方式作为度量标准。

编写复杂代码时,生产率也会发生变化。写一个print语句需要一秒钟,但写一个复杂的逻辑需要很多时间。并非所有的手指都是平等的。

如何利用SLOC为您带来的好处

我认为sloc对于缺陷百分比是一个很好的度量。是的,难度水平发挥了作用,但这是一个很好的参数,经理们可以在做生意的时候到处乱扔。试着从他们的角度思考。他们并不讨厌你或你的工作,但他们需要告诉客户你是最好的,为此他们需要一些切实可行的东西。给他们你能做的:)

可以通过放置额外的空行(“为了可读性”)或放置或删除注释来显著更改SLOC。所以依赖SLOC只会导致混乱。

为什么他们不明白sloc没有改变,但是软件比昨天做的更多,因为你添加了新功能,或者修复了错误?

现在像这样向他们解释。通过比较代码行来测量代码中完成了多少工作,这与测量手机中有多少功能通过大小来比较是一样的。手机的尺寸在20多年的时间里已经减少了,同时由于技术的进步和技术的进步,手机增加了更多的功能。好的代码遵循同样的原则,因为我们可以在越来越少的代码行中表达相同的逻辑,从而使其运行更快、维护更容易,并且在我们改进对问题的理解并引入新的开发技术时更容易理解。

我会让他们关注通过特性开发、维护和错误修复返回的业务价值。如果任何一个对软件满意的人说他们能看到改进,那就不要为sloc担心。

请阅读:

https://stackoverflow.com/questions/3800707/what-is-negative-code