功能点与 kloc 比率作为软件指标...“Name That Tune” 公制？
您如何看待使用函数点到代码行的度量作为度量？
这让我想起了老游戏节目“Name That Tune”。 “我可以用三个音符来命名这首曲子！” 我可以用 0.1 klocs 编写该功能！ 这有用吗？
这看起来肯定会促进图书馆的使用，但这是您想要的吗？
What do you think of using a metric of function point to lines of code as a metric?
It makes me think of the old game show "Name That Tune". "I can name that tune in three notes!" I can write that functionality in 0.1 klocs! Is this useful?
It would certainly seem to promote library usage, but is that what you want?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为这是一个糟糕的主意。 就像按程序员编写的代码行数支付报酬一样糟糕。
一般来说，我更喜欢简洁的代码而不是冗长的代码，但前提是它仍然能够清楚地表达程序员的意图。 最大化每个 kloc 的功能点将鼓励每个人尽可能简短地编写代码，这超出了简洁的范围，而且变得神秘。 它还将鼓励人们将相邻的代码行连接到一行中，即使这种连接在其他情况下是不可取的，只是为了减少代码行数。 允许的最大线路长度也将成为一个问题。
I think it's a terrible idea. Just as bad as paying programmers by lines of code that they write.
In general, I prefer concise code over verbose code, but only as long as it still expresses the programmers' intention clearly. Maximizing function points per kloc is going to encourage everyone to write their code as briefly as they possibly can, which goes beyond concise and into cryptic. It will also encourage people to join adjacent lines of code into one line, even if said joining would not otherwise be desirable, just to reduce the number of lines of code. The maximum allowed line length would also become an issue.
如果您严格执行代码标准，那么 KLOC 是可以容忍的，有点像使用报告的页面要求：不要在一行上放置五个语句或从代码中删除大部分空白。
我想您可以确定它对您的环境有多有效的一种方法是查看几个不同的应用程序和模块，粗略估计代码的质量，并将其与代码的大小进行比较。 如果您可以证明您的组织内的代码质量是一致的，那么 KLOC 并不是一个糟糕的指标。
在某些方面，您将面临与任何类似指标相同的战斗。 如果您计算特性或功能点，或者只是特性或模块，您仍然需要以某种方式对它们进行加权。 最终，您将需要对您将收集的客观数据进行某种主观补充。
KLOC is tolerable if you strictly enforce code standards, kind of like using page requirements for a report: no putting five statements on a single line or removing most of the whitespace from your code.
I guess one way you could decide how effective it is for your environment is to look at several different applications and modules, get a rough estimate of the quality of the code, and compare that to the size of the code. If you can demonstrate that code quality is consistent within your organization, then KLOC isn't a bad metric.
In some ways, you'll face the same battle with any similar metric. If you count feature or function points, or simply features or modules, you'll still want to weight them in some fashion. Ultimately, you'll need some sort of subjective supplement to the objective data you'll collect.
“你认为使用函数点到代码行的度量作为度量怎么样？”
别问这个问题。 对于给定的语言和团队，上述比率是一个简单的统计事实。 并且它趋向于标准差较小的平均值。
有很多自由度：如何计算功能点、使用什么语言、团队（集体）有多聪明。 如果你不改变这些事情，价值就会保持稳定。
一起完成几个项目后，您有一个坚定的期望：在您喜欢的语言/框架/团队组织中，1200 个功能点将是 12,000 行代码。
KSloc / FP 是一个纯粹的统计观察。 显然，还有其他一些事情让你烦恼。 你的问题能说得更具体一些吗？
"What do you think of using a metric of function point to lines of code as a metric?"
Don't get the question. The above ratio is -- for a given language and team -- a simple statistical fact. And it tends toward a mean value with a small standard deviation.
There are lots of degrees of freedom: how you count function points, what language you're using, how (collectively) clever the team is. If you don't change those things, the value stays steady.
After a few projects together, you have a solid expectation that 1200 function points will be 12,000 lines of code in your preferred language/framework/team organization.
KSloc / FP is a bare statistical observation. Clearly, there's something else about this that's bothering you. Could you be more specific in your question?
函数点到代码行的度量实际上用于生成语言级别图表（实际上是函数点到语句），以大致了解编程语言的强大程度。 这是一个示例： http://web.cecs.pdx.edu/ ~timm/dm/functionpoints.html
我不建议将该比率用于其他任何事情，除了像语言级别图表这样的高级近似值。
促进图书馆的使用是一件好事，但要记住的另一件事是，当你建设图书馆时，你会损失比率，并且随着时间的推移，只会以节省的红利来偿还它。 精打细算的人不会明白这一点。
我个人希望看到一个函数点与 ABC 度量比率 - 因为我很好奇 ABC 度量（指示大小并包括作为信息一部分的复杂性）如何关联 - 也许是线性的，也许是指数的，等等...... www.softwarerenovation.com/ABCMetric.pdf
The metric of Function Points to Lines of Code is actually used to generate the language level charts (actually, it is Function Points to Statements) to give an approximate sense of how powerful a programming language is. Here is an example: http://web.cecs.pdx.edu/~timm/dm/functionpoints.html
I wouldn't recommend using that ratio for anything else, except high level approximations like the language level chart.
Promoting library usage is a good thing, but the other thing to keep in mind is you will lose in the ratio when you are building the libraries, and will only pay it off with dividends of savings over time. Bean-counters won't understand that.
I personally would like to see a Function point to ABC metric ratio -- as I am curious about how the ABC metric (which indicates size and includes complexity as part of the info) would relate - perhaps linear, perhaps exponential, etc... www.softwarerenovation.com/ABCMetric.pdf
所有指标都很糟糕。 我的理论一直是，如果你必须拥有它们，那么就用最简单的方法来收集它们并完成它并处理重要的事情。
这通常意味着
如果您正在寻找一个“指标”来跟踪代码效率，那么就不要这样做。 如果您坚持，请再次尝试一些愚蠢但简单的方法，例如源文件大小（请参阅上面的 grep 命令，不带 awk 管道）或 McCabe（带有计数器程序）。
All metrics suck. My theory has always been that if you have to have them, then use the easiest thing you can to gather them and be done with it and onto important things.
That generally means something along the lines of
If you are looking for a "metric" to track code efficency, don't. If you insist, again try something stupid but easy like source file size (see grep command above, w/o the awk pipe) or McCabe (with a counter program).