本文是针对当前业界代码量统计工具现状的分析以及对策。虽然用代码量来代表工作量历来被广大程序员所诟病，但是代码量数据背后确实能够反映出部分软件开发中存在的问题，特别是增量开发，以及维护旧版本的时候，代码增量是很重要的一项参考数据。
代码量统计工具现状
目前研发代码量统计使用的工具是TextDiff和diffcount，主要用于代码量的总量统计和增量统计。但是这两个工具的功能不完善，很多情况下存在统计错误的情况，导致代码量的度量不准确，甚至偏差很大。
典型场景分析
文件重命名
这种情况实际代码没有变化，只是文件名变化，代码变化应该统计为0.实际上两个工具都会认为原有文件被删除，又新增文件。比如原文件1K，统计结果就是新增1K，删除1K。
##文件移动
这种情况实际代码没有变化，只是文件的存放位置变化，代码变化应该统计为0.实际上两个工具都会认为原有文件被删除，又新增文件。比如原文件1K，统计结果就是新增1K，删除1K。
函数移动
这种情况实际代码没有变化，只是函数在文件内部位置变化或者从文件1移动到文件2，代码变化应该统计为0.实际上两个工具都会认为原有函数被删除，又新增一个相同的函数。比如该函数是10行，统计结果就是新增10行，删除10行。
删注释
增删空格和换行
子目录遍历
代码总量统计
上述情况下，这两个工具都存在统计不准确的情况。特别是随着敏捷的推进，不断强化代码的重构，这种情况会更加突出。度量的基础是数据，只有在原始数据准确的前提下，度量才有意义。
| 工具 | 有效代码行 | 函数移动位置 | 文件重命名 | 文件移动位置 | 增删注释 | 空格换行 | 子目录遍历 | 代码总量 |
|---|---|---|---|---|---|---|---|---|
| textdiff | 不算{} | X | X | X | X | X | X | X |
| diffcount | 算{} | X | X | X | X | X | √ | √ |
#解决方案
目前商用和开源代码量统计工具，均没有能完全解决上述问题的。建议自己开发工具。
工具方案：将源代码解析成全局变量声明或者函数（类的方法）这一粒度后，进行比较。 虽然上述方案能最大程度接近真实情况，但是由于实际代码变化的复杂性，不可能完全解析数代码的真实变化情况，还是会存在误差。