源代码行数
来自维基百科，自由的百科全书
源代码行数（Source lines of code）简称SLOC，也称为程序行数（lines of code），简称LOC，是由计算程序源代码的行数来估计计算机程序大小的软件度量。源代码行数一般会用来预计开发程序需要的人力及时间，若在软件完成后，也可以用来估计程序开发生产力或可维护性。
 |
计算方式
许多软件上的比较都只和项目中源代码行数的数量级有关。用源代码行数来比较10,000行源代码和100,000行源代码的项目，会比比较20,000行和21,000行的项目要有效很多。有关源代码行数的计算方式仍有许多不同意见，不过源代码行数的数量级可以做为软件复杂度及评估需要人时的一个指针。
源代码行数计算方式主要可分为两种：实体源代码行数（physical SLOC、LOC）及逻辑源代码行数（logical SLOC、LLOC）。这两种计算方式的具体定义也有很多种，不过最常用的实体源代码行数是直接计算不考虑注解时，代码的行数[1]。
逻辑源代码行数设法计算可执行的“叙述”的数量。但具体定义和使用的编程语言有关（若是针对类似C语言的编程语言，有一种逻辑源代码行数的方式就是计算代码结尾的分号个数）。要制作工具来计算实体源代码行数比较容易，也比较容易说明其定义。不过实体源代码行数会受到一些和逻辑无关的格式及程序风格影响，逻辑源代码行数比较不会受到格式及程序风格影响。在实务上，计算源代码行数时不一定会具体写出其定义，而逻辑源代码行数和实体源代码行数之间会有显著的差异。
以下的C语言程序可以用来说明计算源代码行数的模糊不清之处：
for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */
上例中有：
依照程序设计者及程序设计风格的不同，上述一行实体源代码行数的程序可以写成以下多行的程序：
/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
printf("hello");
}
此例中有
- 4行的实体源代码行数（LOC）：但放括号的工时需要估计进来吗？
- 2行的逻辑源代码行数（LLOC）：看不到重排非叙述代码的影响
- 1行注解
甚至是“实体”及“逻辑”的源代码行数都有许多不同的定义。罗伯特·E·帕克（在他还在软件工程研究所时）等人开发了定义SLOC值的一个框架，让人可以谨慎的说明及定义其项目中用到的SLOC定义及量测方式。例如，大部分软件会有代码复用，在回报量测结果时，如何决定是否要包括代码复用内容就很重要。
起源
人们刚开始用源代码行数来量度软件长度时，当时最常用的语言（像是Fortran及汇编语言）都是行导向的编程语言。当时打孔卡是输入程序的主要方式。一张打孔卡对应一行程序，打孔卡是一张一张的，要计算数量很方便。打孔卡也是程序开发者有形的产出，因此管理者利用计算打孔卡数量来计算程序开发者的生产力是相当合理的。现今最常使用的编程语言在格式上的限制不多，一行的字符数也不止是80个字或是96个字，而一行的文字不一定对应一行的代码。
源代码行数的计算方式
用源代码行数来做为程序相关属性的量度，有些会有些争议。根据多次的实验，已确认源代码行数和开发者所花的工作量高度相关[来源请求]，SLOC越大的程序，开发需要花费的时间及工作量也比较多，因此SLOC若用来估计开发者花的心力，是相当有效的。不过SLOC和机能的相关性很低，熟练的程序设计者可能可以用较少的代码达到相同的机能，因此有可能SLOC较短的程序，其机能甚至有可能比（其他程序员所写）SLOC较长的程序还要多。用SLOC来度量程序设计者的生产力不一定合适，因为有可能程序员只用少少几行程序，达到的机能比其他程序员的许多行程序更多（其他程序员也花了较多的心力）。好的程序设计者会将有重复程序的模块集成成一个模块，提升了程序的质量，但以SLOC的角度来看，反而让SLOC减少了。而且，有经验的程序设计者往往会负责最困难的模块，因此看起来不像其他程序设计者一样的“有生产力”。甚至，没有经验的程序设计者往往会有代码重复的情形，一般而言不鼓励代码重复，因为很不容易维护，很容易有错，但是会有较多的SLOC。
若用SLOC比较不同编程语言写的程序，除非有针对不同语言的特性进行正规化，不然其准确度就更低了。各种的计算机语言都设法在简洁及清楚这两方面来取舍，有些强调简洁，有些则强调清楚。以极端的例子来说，汇编语言会需要上百行的程序，来完成APL语言几个字即可完成的工作。以下是C语言及COBOL所写的Hello World示例程序的比较：
| C | COBOL |
|---|---|
#include <stdio.h>
int main() {
printf("Hello world\n");
}
|
identification division.
program-id. hello .
procedure division.
display "hello world"
goback .
end program hello .
|
| 源代码行数：4 （不算空白） |
源代码行数：6 （不算空白） |
在使用SLOC来计算程序设计者的努力时，另一个常见的问题是人工写的程序以及自动产生程序的差异。许多现代的软件工具都可以在鼠标点击一些设置，或是摆放对象之后，自动生成一大段的程序。例如只要将一些图案移到工作区，图形用户界面产生器就会自动产生对应控件的大量程序。这个工作量完全不能和写设备驱动程序的工作量相比。但两者产生的代码长度可能差异不大，这也是用SLOC来计算的缺点。
目前有许多成本、时程及工作量估计的模型，会用SLOC为输入引数，包括巴里·勃姆等人建立，广为使用的构造性成本模型（COCOMO）、PRICE系统、True S及Galorath的SEER-SEM。这些模型的预测能力都很好，但程度会和给模型的输入资料（尤其是SLOC估计值）准确程度有关。有些软件工程研究者[2]建议用功能点代替SLOC，不过因为功能点和SLOC高度相关，而且无法自动计算，因为各研究者对此论点的看法还没有共识。
依照Vincent Maraia的统计[3]，微软 Windows NT中不同时期的操作系统其SLOC如下：
针对Debian2.2版（Windows NT）以后的操作系统，也有类似的统计，Debian GNU/Linux 2.2有55 million SLOC，依传统私用程序的开发方式，需要14,005人年，需要花190亿美金。
评论
- 可以自动化计算：因为源代码行数是程序的实体特质，可以用计算行数的程序来取代人工的行数计算。有许多小的程序可以计算软件的源代码行数，不过因为各语言的语法及结构特性不同，针对一种语言计算逻辑源代码行数的程序可能无法计算其他语言的逻辑源代码行数。若是要计算实体源代码行数，已有可以适用于数十种语言的软件。
- 符合直觉的度量：源代码行数是符合直觉的软件度量标准，易于计算。也有研究者认为用功能点来度量软件，不过功能点不是程序的实体特质，是逻辑上的概念。而源代码行数没有这类问题，就算是经历不多的程序员也可以用源代码行数来量测软件大小。
- 无所不在的度量方式：自从软件开发的最早期开始，就已经出现源代码行数的计算[9]。因此，可以说，源代码行数的资料会比其他软件度量方式的资料会多很多。
- 无法反映实际的工作量。用源代码行数来计算软件开发的生产力，有些基本层面的问题。有些研究者认为不能只用编写程序阶段产生的成果来估算项目的产出，一般而言，编写程序阶段只占整体的30%至35%。
- 缺乏有关功能凝聚力的信息：软件开发者付出的心力可能和源代码行数的相关性较高，但其程序的机能性和源代码行数的关系较小。有经验的程序设计者可以用较短的代码达到相同的功能。甚至，一些较熟练的软件开发者，会用重构的方式，设计调整程序，去除多余的程序，程序会变的较精简，也比较理想，但以源代码行数来看，看不到这方面的贡献。
- 心理学上的问题：若程序设计者的产出是用源代码行数来估算，难免他会调整程序写法，让相同机能的程序可以有较多行数的源代码。
在公共广播电视公司的记录片《Triumph of the Nerds》中，微软的首席执行官史蒂夫·鲍尔默曾评论过计算源代码行数的作法：
在IBM里有一种软件中的文化，是要计算K-LOC，K-LOC就是一千行程序。项目有多大？这个项目大约是10K-LOC的项目，这个人是写20K-LOC程序的人，这个代码有50K-LOC。IBM想要调整这种有关K-LOC以及员工薪资的作法。我们在OS/2上面花费了多少钱，也就是他们工作可换来的钱。你写了多少K-LOC的程序？我们设法说服程序设计者，若开发者有好的想法，让一个程序可以不需要20K-LOC的代码，只要4K-LOC的代码就可以达到相同目的，为什么我们应该要少付一点钱？就因为他让程序变的更小又更快了？让K-LOC减少了？这是我们的方法论。
相关名词
相关条目
- 软件开发工作量预估
- 预估 (项目管理)
- 软件工程的成本预估
- 软件大小预估
参考资料
延伸阅读
外部链接
Wikiwand - on
Seamless Wikipedia browsing. On steroids.