考虑到h文件中LOC的数量，我能估算出最佳代码（桌面应用程序）中C ++ LOC的数量是多少？
背景： 我正在做一个努力估算和一个将C ++软件移植到C＃的计划。
我的第一个想法是基于LOC创建粗略估计，并使用移植到剩余LOC的LOC来跟踪过程。假设移植速度为200LOCs /天，我达到了1.5人年。如果我向客户提供这个数字，我当然不会得到合同。
仔细查看我发现的代码后，代码效率非常低，使用了许多C＆amp; P代码，实现了自己的容器类等。 因此，C ++的LOC-Number似乎并不反映实现相同功能的努力。现在我的假设是，头文件应该更好地反映功能。
答案 0 :(得分：2)
没有。头文件的大小是相关代码文件大小的非常糟糕的代理。标题只显示API的入口点，它可以隐藏API所需的内容。
换句话说，声明单个函数的标题只表示该实现文件中有一个公共函数。实现文件中只能包含一个函数，或者可能有数百个函数。它们都不是更好，两种开发方法都没有错。这只是意味着您无法使用标头来估算工作量。
使用100k SLOCs程序，使用SLOC作为衡量标准将是一个延伸，因为您将花费更多时间进行测试而不是开发。如果您可以访问应用程序的功能文档，请考虑使用function points。据我所知，他们是一个不那么破碎的启发式方法。
就开发而言，不要忘记您可以从C＃调用C ++代码并且C ++ / CX可以集成C＃。如果您可以逐步重写或多或少独立的组件，这可以减轻一些移植痛苦。
答案 1 :(得分：1)
头文件可能不是指示符。
头文件通常包含函数声明 - 关于如何调用函数的接口或指令。
源文件中的函数可以是零语句或数百个LOC。通过查看函数声明，无法分辨函数中的语句或行数。
许多LOC计数器都包含头文件和源文件。
答案 2 :(得分：1)
不是出于同样的目标，但是出于我的好奇心，我曾用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对任何事情都不是一个好的指标。但与其他指标一起，例如注释线可以绘制一些模糊线以指示不同的参数和发展阶段。需要对众所周知的代码库进行更多研究才能找到一个好的方法。
但最后无论你采取什么措施，它都可以得出一个可能错误的假设。