需要代码度量。最佳代码中 h 文件中的 LOC 与 cpp 文件中的 LOC 的比率答案

【问题标题】：Code metric required. Ratio of LOCs in h-files to LOCs in cpp-files in optimal code需要代码度量。最佳代码中 h 文件中的 LOC 与 cpp 文件中的 LOC 的比率
【发布时间】：2015-08-09 14:48:10
【问题描述】：

在给定 h 文件中的 LOC 数量的情况下，我能否估算出最佳代码（桌面应用程序）中 C++ LOC 的数量是多少？

背景：我正在做一个将 C++ 软件移植到 C# 的工作量估算和计划。

我的第一个想法是根据 LOC 进行粗略估计，并使用移植到剩余 LOC 的 LOC 来跟踪流程。假设移植速度为 200LOCs/day 我来到 1,5 人年。如果我把这个数字给客户，我肯定不会得到合同。

仔细查看代码后发现，代码效率非常低，使用多对多 C&P 代码，实现自己的容器类等。所以 C++ 的 LOC-Number 似乎没有反映实现相同功能的努力。现在我的假设是，头文件应该更好地反映功能。

【问题讨论】：

LOC 总是最糟糕的指标。静态代码分析有更好的启发式方法。
没有上下文且未清除代码 - 是的，您不能依赖 LOC。但是清除 LOC（删除 cmets、未使用、冗余代码、根据样式指南实现代码等）并了解上下文（程序语言、应用程序类型、行业）， LOC 仍然是很好的衡量标准。
“使用自己的容器类”的问题是它们通常有问题。不一定，但是那种聪明到可以正确编写它们的程序员也足够聪明，可以不首先编写它们。这意味着您将花费大量时间来处理这些代码行，要么重写该容器的用途，要么模仿其损坏的行为。

标签： c++ software-estimation

【解决方案1】：

没有。头文件的大小不能很好地代表相关代码文件的大小。标头仅显示 API 的入口点，它可以根据 API 的需要隐藏尽可能多或尽可能少的内容。

换句话说，声明单个函数的标头仅表示该实现文件中有一个公共函数。实现文件中可能只有一个函数，也可能有数百个函数。它们都不是更好，这两种开发方法都没有错。这只是意味着您不能使用标题来估计工作量。

对于 100k SLOC 计划，使用 SLOC 作为衡量标准会有些牵强，因为您将花费更多时间进行测试而不是开发。如果您有权访问应用程序的功能文档，请考虑改用function points。据我所知，它们是周围较少破坏的启发式方法之一。

就开发而言，不要忘记您可以从 C# 调用 C++ 代码，并且 C++/CX 可以集成 C#。如果您可以增量地重写或多或少的独立组件，这可以减轻一些移植的痛苦。

【讨论】：

头文件应该反映数据模型。 CPP-Files 中的代码实现了工作流。现有许多建议，例如每个函数的最佳位置数等。因此，拥有一个数据模型，估计软件的最佳大小应该是可行的。
@ValentinHeinitz 但是它并没有反映所需的实现复杂性，这使它成为一个不好的措施。
@ValentinHeinitz，对建议的函数大小有估计，但此函数的调用图没有限制，并且标头不导出的函数数量没有限制。标题中可以有 3 个函数，但如果 .cpp 中有 45 个函数（有 42 个static），即使它们都有“推荐的行数”，你也会得到完全错误的图像。
@zneak 哦，我明白了。代码的结构非常经典——所有声明都在 h 文件中，都在 cpp 中实现。即使代码使用了 pimpl idiom（不是这种情况），我也可以访问所有 h 文件，无论是私有的还是公共的。所以有 1400 个函数、1500 个成员变量和 400 个枚举。

【解决方案2】：

不是出于相同的目标，但是出于好奇，我曾经使用cloc 检查了我的 LOC，以了解处于中间（alpha 前）阶段的项目。它没有得到很好的记录，它的一些地方编码有点脏或没有很好的计划。

C++                             100           2545           3252          11680
C/C++ Header                    108           2847          12721           9077
C                                 4           1080            971           6298
CMake                            33            241            161           1037
Bourne Shell                      4             16              0            709
Python                            8             90             72            423
CSS                               1             63             21            422
PHP                               5             23             21            295
Javascript                        5             42             23            265
JSON                              4              0              0            183
XML                               1             11            171             72
make                              1             13              0             15
Bourne Again Shell                2             10              0             14

如您所见，标头 LOC 和源 LOC 之间的比率为 0.777。但是average 不是衡量任何事物的好指标。但与其他指标一起，例如注释线可能会画出一些模糊线来表示不同的参数和开发阶段。需要对众所周知的代码库进行更多的研究才能提出一个好的启发式方法。

但最终无论你采取什么措施，它都可以得出一个可能是错误的假设。

【讨论】：

感谢您的见解！看起来你是唯一一个读到最后的人 :-) 当然，平均值很少准确。我更喜欢 Steve McConnell 在他的“软件估计”一书中给出代码度量的方法。总是有表格，而不是单个值。根据软件的项目艺术（桌面、嵌入式、网络、汽车、商业等）和大小，特定指标总是有不同的值。
如果您可以研究一些开源项目及其指标和演变并提出一些出版物，这将是一项很好的研究工作。这将是一篇有趣的论文。

【解决方案3】：

头文件可能不是指标。

头文件通常包含函数声明——关于如何调用函数的接口或说明。

源文件中的函数可以是零个语句或数百个 LOC。无法通过查看函数声明来判断函数中的语句或行数。

许多 LOC 计数器包括头文件和源文件。

【讨论】：