考虑到 h 文件中 LOC 的数量，我能否估计一下，最佳代码（桌面应用程序）中 C++ LOC 的数量是多少？
背景：我正在做一个将 C++ 软件移植到 C# 的工作量估算和计划。
我的第一个想法是根据 LOC 创建粗略估计，并使用移植到剩余 LOC 的 LOC 跟踪过程。假设移植速度为 200LOCs/day 我来到 1,5 人年。如果我把这个数字呈现给客户，我肯定不会得到合同。
仔细查看代码后，我发现该代码效率非常低，使用多对多 C&P 代码，实现自己的容器类等。所以 C++ 的 LOC-Number 似乎没有反映实现相同的努力功能。现在我的假设是，头文件应该更好地反映功能。
不，头文件的大小不能很好地代表相关代码文件的大小。标头仅显示 API 的入口点，它可以根据 API 的需要隐藏尽可能多或尽可能少的内容。
换句话说，声明单个函数的标头仅表示该实现文件中有一个公共函数。实现文件中可能只有一个函数，也可能有数百个。它们都不是更好，这两种开发方法都没有错。这只是意味着您不能使用标题来估计工作量。
对于 100k SLOC 程序，使用 SLOC 作为衡量标准会有些牵强，因为您将花费更多时间进行测试而不是开发。如果您有权访问应用程序的功能文档，请考虑改用功能点。据我所知，它们是周围较少破坏的启发式方法之一。
就开发而言，不要忘记您可以从 C# 调用 C++ 代码，并且 C++/CX 可以集成 C#。如果您可以增量地重写或多或少的独立组件，这可以减轻一些移植痛苦。
头文件可能不是指标。
头文件通常包含函数声明——关于如何调用函数的接口或指令。
源文件中的函数可以是零个语句或数百个 LOC。不能通过查看函数声明来判断函数中的语句或行数。
许多 LOC 计数器包括头文件和源文件。
不是出于相同的目标，但是出于好奇，我曾经检查过我的 LOC，以cloc了解处于中间（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，这不是衡量任何事情的好指标。但是与其他指标（例如注释行）一起，可能会绘制一些模糊线以指示不同的参数和发展阶段。需要对众所周知的代码库进行更多的研究才能提出一个好的启发式方法。
但最终无论你采取什么措施，它都可以得出一个可能是错误的假设。