使用源代码行数来评估软件的规模，一直以来是软件规模评估最常用的方法。
所以如此，是因为软件规模源代码行评价法比较简单，只要数出代码行的数量即可，而且这个代码行数也很客观，无论用户还是开发人员，使用相同的工具遵循相同的规则就可以得到相同的结果。
但应用代码行作为评价软件项目规模的方法，其缺点也是显而易见的。
首先，代码行从技术而非业务角度度量软件规模。
软件源代码行法就是以完成的软件源代码的数量表示软件项目所完成的功能的多少，对于开发人员来说，代码行数能够体现他们的编程实现的水平和辛苦，但是对于用户或其他项目外部干系人来说，代码行没有什么意义，他们更关心是实现的功能，而且他们对开发人员给出的代码行数也会抱有怀疑——我怎么知道给出的代码行数是不是最合适的，开发人员会不会为了提高报价故意不对代码进行优化重构？
正是因为代码行数不能被用户所信服，所以当使用代码行数作为衡量软件开发费用的基础时也难以获得用户的信任。
其次，代码行度量不及时。
准确的代码行数只有在软件开发完成并且通过用户的验收之后才能得到，在此之前的代码行数都不是准确的。而在开发之前的报价、开发之初的策划都需要软件规模数据，这时的规模数据只能是靠开发人员的估计得来，这个估计值肯定是不准确的，不同的人员估计结果会有50%以上的偏差，估计结果与实际结果的偏差也经常会超出20%。这就使得软件报价有很多水分，软件策划与实际偏差很大。
第三，缺乏代码行度量标准。
虽然IEEE和SEI颁布了一些代码行度量标准，但它们并没有得到广泛的接受。所以一行代码是多长？注释语句是否计算在代码行数之内？跨行的语句算一行还是多行？……这些在行业中并没有一致的规定。
而且，不同开发语言实现同一功能点的代码行是不同的，如果使用多语言开发的软件，软件的规模如何进行归一化呢？即使已经有了一个不同开发语言代码行数的换算关系，但它也很难覆盖不断涌现的新的开发语言。
正是由于软件规模的源代码行评估方法的一致性不容易得到保证，越来越多的软件开发组织倾向于采用功能点来衡量软件项目的规模。
这正是：
评估规模代码行，常用方法都知翔
优点缺点全都有，使用之时要思量
参考书目：软件项目功能点度量方法与应用，作者：曹济 温丽，出版社：清华大学出版社
联系客服
