functional-programming - 功能点与 kloc 比率作为软件指标......“名称调整”指标？

Question

您如何看待使用功能点到代码行的度量作为度量？

这让我想起了旧游戏节目“Name That Tune”。“我可以用三个音符来命名那首曲子！” 我可以在 0.1 klocs 中编写该功能！这有用吗？

它似乎肯定会促进图书馆的使用，但这是你想要的吗？

Answer 1

我认为这是一个可怕的想法。就像按他们编写的代码行向程序员支付报酬一样糟糕。

一般来说，我更喜欢简洁的代码而不是冗长的代码，但前提是它仍然清楚地表达了程序员的意图。最大化每个 kloc 的功能点将鼓励每个人尽可能简短地编写他们的代码，这超出了简洁性和神秘性。它还将鼓励人们将相邻的代码行合并为一行，即使这种合并在其他情况下是不可取的，只是为了减少代码行数。允许的最大行长度也将成为一个问题。

Answer 2

如果您严格执行代码标准，KLOC 是可以容忍的，有点像使用报告的页面要求：不要将五个语句放在一行或从代码中删除大部分空白。

我想你可以决定它对你的环境有多有效的一种方法是查看几个不同的应用程序和模块，粗略估计代码的质量，并将其与代码的大小进行比较。如果您可以证明您的组织内的代码质量是一致的，那么 KLOC 就不是一个糟糕的指标。

在某些方面，您将面临使用任何类似指标的相同战斗。如果你计算特性或功能点，或者只是特性或模块，你仍然希望以某种方式对它们进行加权。最终，您需要对要收集的客观数据进行某种主观补充。

Answer 3

“您如何看待使用功能点到代码行的度量作为度量？”

不明白这个问题。对于给定的语言和团队，上述比率是一个简单的统计事实。它趋向于具有较小标准偏差的平均值。

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?

Answer 4

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

grep -c ";" *.h *.cpp | awk -F: '/:/ {x += $2} END {print x}'

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).

Answer 5

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