The issue with SLOC is that it's an easy metric to game. Being productive does not equate to producing more code. So the way I've explained it to people baring what Skilldrick said is this:
The more lines of code there are the more complicated something gets.
The more complicated something gets, the harder it is to understand it.
Before I add a new feature or fix a bug I need to understand it.
Understanding takes time.
Time costs money.
Smaller code -> easier to understand -> cheaper to add new features
It doesn't take long to explain how a for loop works.
After you show them this, say "we now need to print numbers up to 100 - here's how you make that change." and show how much longer it takes to change the non-DRY code.
I disagree on SLOC being a bad metric. It may be moot to go into a years-old question with eleven answers, but I'll still add another.
Most arguments call it a bad metric because it is not suited to directly measure productivity. That is a strange argument; it assumes the metric to be used in an insane way. With this reasoning, one could call the Kelvin a bad unit because it is unsuited to measure distance.
Code length is a viable measure of ballast.
The amount of non-comment code lines correlates with:
undetected errors
maintenance costs
training time for new contributors
migration costs
new feature costs
and many more similar kinds of costs, like the cost of optimization.
Of course SLOC count isn't a precise measure of any of these. Code can be anywhere between very nice and very ugly to manage. But it can be assumed that code length is rarely free, and thus, longer code is often harder to manage.
If I were managing a team of programmers, I would very much want to keep track of the ballast it creates or removes.
Explain that SLOC is an excellent measurement of the lines of code in the application, nothing else.
The number of lines in a book, or the length of a film doesn't determine how good it is. You can improve a film and shorten it, you can improve an application and reduce the lines of code.
A much better idea would to cover the test cases, rather than code.
The idea is this: a developer should commit a test case that fails, then commit the fix in next build, and the test case should pass ... just measure how many test cases the developer added.
As a bonus collect coverage stats (branch coverage is better than line coverage here).
I believe SLOC is a great metric. It tells you how large your system is. That is good for judging complexity and resources. And it helps you prepare the next developer for working on a codebase.
But SLOC count should be analyzed only AFTER other appropriate code quality metrics have been applied. So...
Do NOT write 2 lines of code when 1 will do, unless the 2-line version makes the code 2 times easier to maintain.
Do NOT fluff code with unnecessary comments just to fluff SLOC count.
Do NOT pay people by SLOC count.
I have been managing software projects for 30 years. I use SLOC count all the time, to help understand mature systems. I have never found it useful to even glance at SLOC count until a project is near version 1.0 release.
Basically, during the development process, I worry about quality, performance, usability, and conformance to specifications. Get those right, and the project will probably be a success. When the dust settles, look at SLOC count. You might be surprised that you got SO much out of 5,000 lines of code. And you might be surprised that you got SO little! (But SLOC count does not affect quality, performance, usability, and conformance to specification.)
And always code like the person who will be working on your code next is a violent psychopath who knows where you live.
You don't judge how good(how many features,how it performs..) a plane is based on its weight(sloc).
When you want your plane to fly higher, longer and perform better, you don't add weight to it. You replace parts of it with lighter/better materials. You strip off parts you don't need as to not add unnecessary weight.
Why SLOC is bad as an individual metric of productivity
Think of code as a block of clay/stone. You need to carve, say 10 statues. It's not how many statues you carve that counts. It's how well you've carved it that counts. Similarly it's not how many lines you've written but how well they are functioning. In case of code LOC can backfire as a metric this way.
Productivity also changes when writing a complex piece of code. It takes a second to write a print statement but a lot of time to write a complex piece of logic. Not all fingers are equal.
How SLOC can be used to your benefit
I think SLOC for defect % is a good metric. Yes the difficulty level comes into play but this is a good parameter that the managers can throw around while doing business. Try to think from their perspective too. They don't hate you or your work, but they need to tell customers that you're the best and for that they need something tangible. Give them what you can :)
SLOC can be changed dramatically by putting extra empty lines ("for readability") or by putting or removal of comments. So relying on SLOC only can lead to confusion.
Why don't they understand that the SLOC hasn't changed, but the software does more than it did yesterday because you've added new features, or fix bugs?
Now explain it to them like this. Measuring how much work was done in your code by comparing the lines of code is the same as measuring how many features are in your cell phone comparing it by size. Cell phones have decreased in size over 20 years time while adding more features because of technological improvements and techniques. Good code follows this same principal as we can express the same logic in fewer and fewer lines of code, making it faster to run, easier to maintain, and simpler to understand as we improve our understanding of the problem and introduce new techniques for development.
I would get them to focus on the business value returned through feature development, maintenance, and bug fixes. If whoever is happy with the software says they can see improvement don't sweat the SLOC.
发布评论
评论（13）
有人说：
“使用 SLOC 来衡量软件进度就像用 kg 来衡量飞机制造进度一样”
这是完全不合适的，因为它鼓励了不良做法，例如：
复制粘贴综合症
填充无意义的注释
...
唯一的用途是当您打印完整的源代码树时，它可以帮助您估计要在打印机中放入多少纸张。
Someone said :
"Using SLOC to measure software progress is like using kg for measuring progress on aircraft manufacturing"
It is totally inappropriate as it encourages bad practices like :
Copy-Paste-Syndrome
discourage refactoring to make things easier
Stuffing with meaningless comments
...
The only use is that it can help you to estimate how much paper to put in the printer when you do a printout of the complete source tree.
SLOC 的问题在于它是一个容易被玩弄的指标。高效并不等于生成更多代码。所以我向人们解释它的方式就像 Skilldrick 所说的那样：
较小的代码 ->更容易理解->添加新功能更便宜
豆计数器可以理解这一点。
The issue with SLOC is that it's an easy metric to game. Being productive does not equate to producing more code. So the way I've explained it to people baring what Skilldrick said is this:
Smaller code -> easier to understand -> cheaper to add new features
Bean counters can understand that.
向他们展示以下之间的区别：
和
并询问他们 10 个 SLOC 还是 3 个 SLOC 更好。
回应评论：
不需要很长时间就能解释
for循环的工作原理。向他们展示此内容后，请说“我们现在需要打印最多 100 个数字 - 以下是您进行更改的方法。”并显示更改非 DRY 代码需要多长时间。
Show them the difference between:
and
And ask them whether 10 SLOC or 3 SLOC is better.
In response to the comments:
It doesn't take long to explain how a
forloop works.After you show them this, say "we now need to print numbers up to 100 - here's how you make that change." and show how much longer it takes to change the non-DRY code.
我不同意 SLOC 是一个糟糕的指标。讨论一个有十一个答案的多年问题可能没有意义，但我仍然会添加另一个。
大多数争论称它是一个糟糕的指标，因为它不适合直接衡量生产力。这是一个奇怪的论点；它假设该指标以疯狂的方式使用。根据这个推理，人们可以称开尔文为一个糟糕的单位，因为它不适合测量距离。
代码长度是镇流器的一个可行的衡量标准。
非注释代码行的数量与以下因素相关：
以及许多其他类似类型的成本，例如优化成本。
当然，SLOC 计数并不是对其中任何一个的精确衡量。代码的管理方式可能介于非常好和非常难管理之间。但可以假设代码长度很少是自由的，因此较长的代码通常更难管理。
如果我管理一个程序员团队，我非常希望跟踪它创建或删除的镇流器。
I disagree on SLOC being a bad metric. It may be moot to go into a years-old question with eleven answers, but I'll still add another.
Most arguments call it a bad metric because it is not suited to directly measure productivity. That is a strange argument; it assumes the metric to be used in an insane way. With this reasoning, one could call the Kelvin a bad unit because it is unsuited to measure distance.
Code length is a viable measure of ballast.
The amount of non-comment code lines correlates with:
and many more similar kinds of costs, like the cost of optimization.
Of course SLOC count isn't a precise measure of any of these. Code can be anywhere between very nice and very ugly to manage. But it can be assumed that code length is rarely free, and thus, longer code is often harder to manage.
If I were managing a team of programmers, I would very much want to keep track of the ballast it creates or removes.
说明 SLOC 是应用程序中代码行数的绝佳衡量标准，除此之外。
一本书的行数或电影的长度并不能决定多么好啊。您可以改进电影并缩短它，您可以改进应用程序并减少代码行数。
Explain that SLOC is an excellent measurement of the lines of code in the application, nothing else.
The number of lines in a book, or the length of a film doesn't determine how good it is. You can improve a film and shorten it, you can improve an application and reduce the lines of code.
非常糟糕（-：
更好的想法是覆盖测试用例，而不是代码。
这个想法是这样的：开发人员应该提交失败的测试用例，然后在下一个构建中提交修复，并且测试用例应该通过。 .. 只需测量开发人员添加了多少测试用例即可
作为奖励收集覆盖率统计数据（此处分支覆盖率优于行覆盖率）。
Pretty bad (-:
A much better idea would to cover the test cases, rather than code.
The idea is this: a developer should commit a test case that fails, then commit the fix in next build, and the test case should pass ... just measure how many test cases the developer added.
As a bonus collect coverage stats (branch coverage is better than line coverage here).
我相信 SLOC 是一个很好的指标。它告诉您系统有多大。这有利于判断复杂性和资源。它可以帮助您为下一个开发人员处理代码库做好准备。
但是，只有在应用其他适当的代码质量指标之后才应分析 SLOC 计数。所以...
版本使代码更容易维护 2 倍。
我管理软件项目已有 30 年了。我一直使用 SLOC 计数来帮助理解成熟的系统。在项目接近版本 1.0 发布之前，我从未发现查看 SLOC 计数有什么用。
基本上，在开发过程中，我担心质量、性能、可用性和规范的一致性。把这些做好，这个项目就可能会成功。当尘埃落定后，查看 SLOC 计数。您可能会惊讶于您从 5,000 行代码中得到了这么多。你可能会惊讶自己得到的这么少！ （但是 SLOC 计数不会影响质量、性能、可用性和对规范的一致性。）
并且始终像下一个将在您的代码上工作的人是一个知道您住在哪里的暴力精神病患者一样进行编码。
干杯，
芯片叔叔
I believe SLOC is a great metric. It tells you how large your system is. That is good for judging complexity and resources. And it helps you prepare the next developer for working on a codebase.
But SLOC count should be analyzed only AFTER other appropriate code quality metrics have been applied. So...
version makes the code 2 times easier to maintain.
I have been managing software projects for 30 years. I use SLOC count all the time, to help understand mature systems. I have never found it useful to even glance at SLOC count until a project is near version 1.0 release.
Basically, during the development process, I worry about quality, performance, usability, and conformance to specifications. Get those right, and the project will probably be a success. When the dust settles, look at SLOC count. You might be surprised that you got SO much out of 5,000 lines of code. And you might be surprised that you got SO little! (But SLOC count does not affect quality, performance, usability, and conformance to specification.)
And always code like the person who will be working on your code next is a violent psychopath who knows where you live.
Cheers,
Uncle Chip
你不能根据飞机的重量（sloc）来判断一架飞机有多好（有多少功能，它的性能如何......）。
当您希望您的飞机飞得更高、更长、性能更好时，您就不会增加飞机的重量。您可以用更轻/更好的材料替换其中的一部分。您可以去掉不需要的部件，以免增加不必要的重量。
You don't judge how good(how many features,how it performs..) a plane is based on its weight(sloc).
When you want your plane to fly higher, longer and perform better, you don't add weight to it. You replace parts of it with lighter/better materials. You strip off parts you don't need as to not add unnecessary weight.
即使现代代码度量工具也批评 SLOC conting，我喜欢 ProjectCodeMeter FAQ 中提出的观点：
出了什么问题计算代码行数（SLOC / LLOC）？
even modern code metrics tools criticize SLOC conting, i like the point made in the ProjectCodeMeter FAQ:
What's wrong with counting Lines Of Code (SLOC / LLOC)?
为什么 SLOC 作为单独的生产力指标是不好的
将代码视为一块粘土/石头。你需要雕刻 10 个雕像。重要的不是你雕刻了多少雕像。重要的是你雕刻得有多好。同样，重要的不是你写了多少行，而是它们的运行情况。如果使用代码 LOC，这种方式可能会适得其反。
编写复杂的代码时，生产力也会发生变化。写一条打印语句需要一秒钟，但写一段复杂的逻辑却需要很多时间。并非所有手指都是平等的。
如何利用 SLOC 为您带来好处
我认为缺陷百分比的 SLOC 是一个很好的指标。是的，难度级别会发挥作用，但这是管理者在开展业务时可以使用的一个很好的参数。也尝试从他们的角度思考。他们并不讨厌你或你的工作，但他们需要告诉客户你是最好的，为此他们需要一些有形的东西。给他们你能做的:)
Why SLOC is bad as an individual metric of productivity
Think of code as a block of clay/stone. You need to carve, say 10 statues. It's not how many statues you carve that counts. It's how well you've carved it that counts. Similarly it's not how many lines you've written but how well they are functioning. In case of code LOC can backfire as a metric this way.
Productivity also changes when writing a complex piece of code. It takes a second to write a print statement but a lot of time to write a complex piece of logic. Not all fingers are equal.
How SLOC can be used to your benefit
I think SLOC for defect % is a good metric. Yes the difficulty level comes into play but this is a good parameter that the managers can throw around while doing business. Try to think from their perspective too. They don't hate you or your work, but they need to tell customers that you're the best and for that they need something tangible. Give them what you can :)
通过添加额外的空行（“为了可读性”）或添加或删除注释，可以极大地改变 SLOC。因此仅依赖 SLOC 可能会导致混乱。
SLOC can be changed dramatically by putting extra empty lines ("for readability") or by putting or removal of comments. So relying on SLOC only can lead to confusion.
为什么他们不明白 SLOC 没有改变，但软件比昨天做了更多的事情，因为您添加了新功能或修复了错误？
现在像这样向他们解释一下。通过比较代码行数来衡量代码中完成了多少工作，与通过大小比较来衡量手机中有多少功能相同。 20 年来，由于技术的进步和技术的进步，手机的尺寸不断缩小，同时又增加了更多的功能。好的代码遵循同样的原则，因为我们可以用越来越少的代码行表达相同的逻辑，随着我们提高对问题的理解并引入新技术进行开发，使其运行速度更快、维护更容易、更容易理解。
我会让他们专注于通过功能开发、维护和错误修复所返回的业务价值。如果对软件感到满意的人说他们可以看到改进，那么就不要担心 SLOC。
去读这个：
https://stackoverflow.com/questions/3800707/what-is-male-code< /a>
Why don't they understand that the SLOC hasn't changed, but the software does more than it did yesterday because you've added new features, or fix bugs?
Now explain it to them like this. Measuring how much work was done in your code by comparing the lines of code is the same as measuring how many features are in your cell phone comparing it by size. Cell phones have decreased in size over 20 years time while adding more features because of technological improvements and techniques. Good code follows this same principal as we can express the same logic in fewer and fewer lines of code, making it faster to run, easier to maintain, and simpler to understand as we improve our understanding of the problem and introduce new techniques for development.
I would get them to focus on the business value returned through feature development, maintenance, and bug fixes. If whoever is happy with the software says they can see improvement don't sweat the SLOC.
Go read this:
https://stackoverflow.com/questions/3800707/what-is-negative-code