原始码行数
原始码行数（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如下：
| 年份 | 操作系统 | SLOC（百万） |
|---|---|---|
| 1993 | Windows NT 3.1 | 4–5[3] |
| 1994 | Windows NT 3.5 | 7–8[3] |
| 1996 | Windows NT 4.0 | 11–12[3] |
| 2000 | Windows 2000 | 29以上[3] |
| 2001 | Windows XP | 45[4][5] |
| 2003 | Windows Server 2003 | 50[3] |
针对Debian2.2版（Windows NT）以后的操作系统，也有类似的统计，Debian GNU/Linux 2.2有55 million SLOC，依传统私用程序的开发方式，需要14,005人年，需要花190亿美金。
| 年份 | 操作系统 | SLOC（百万） |
|---|---|---|
| 2000 | Debian 2.2 | 55–59[6][7] |
| 2002 | Debian 3.0 | 104[7] |
| 2005 | Debian 3.1 | 215[7] |
| 2007 | Debian 4.0 | 283[7] |
| 2009 | Debian 5.0 | 324[7] |
| 2012 | Debian 7.0 | 419[8] |
评论
优点
- 可以自动化计算：因为原始码行数是程序的实体特质，可以用计算行数的程序来取代人工的行数计算。有许多小的程序可以计算软件的原始码行数，不过因为各语言的语法及结构特性不同，针对一种语言计算逻辑原始码行数的程序可能无法计算其他语言的逻辑原始码行数。若是要计算实体原始码行数，已有可以适用于数十种语言的软件。
- 符合直觉的度量：原始码行数是符合直觉的软件度量标准，易于计算。也有研究者认为用功能点来度量软件，不过功能点不是程序的实体特质，是逻辑上的概念。而原始码行数没有这类问题，就算是经历不多的程序员也可以用原始码行数来量测软件大小。
- 无所不在的度量方式：自从软件开发的最早期开始，就已经出现原始码行数的计算[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减少了？这是我们的方法论。
相关名词
相关条目
参考资料
- ^ Vu Nguyen; Sophia Deeds-Rubin; Thomas Tan; Barry Boehm, A SLOC Counting Standard (PDF), Center for Systems and Software Engineering, University of Southern California, 2007 [2020-01-10], （原始内容 (PDF)存档于2012-04-17）
- ^ IFPUG "Quantifying the Benefits of Using Function Points" （页面存档备份，存于互联网档案馆）
- ^ 3.0 3.1 3.2 3.3 3.4 3.5 How Many Lines of Code in Windows?. Knowing.NET. December 6, 2005 [2010-08-30]. （原始内容 (Scholar search)存档于2014-05-18）.
This in turn cites Vincent Maraia's The Build Master as the source of the information. - ^ How Many Lines of Code in Windows XP?. Microsoft. January 11, 2011 [2020-01-10]. （原始内容存档于2019-11-04）.
- ^ A history of Windows. Microsoft. [2020-01-10]. （原始内容存档于2016-06-18）.
- ^ González-Barahona, Jesús M., Miguel A. Ortuño Pérez, Pedro de las Heras Quirós, José Centeno González, and Vicente Matellán Olivera. Counting potatoes: the size of Debian 2.2. debian.org. [2003-08-12]. （原始内容存档于2008-05-03）.
- ^ 7.0 7.1 7.2 7.3 7.4 Robles, Gregorio. Debian Counting. [2007-02-16]. （原始内容存档于2013-03-14）.
- ^ Debian 7.0 was released in May 2013. The number is an estimate published on 2012-02-13, using the code base which would become Debian 7.0, using the same software method as for the data published by David A. Wheeler. James Bromberger. Debian Wheezy: US$19 Billion. Your price… FREE!. [2014-02-07]. （原始内容存档于2014-02-23）.
- ^ IFPUG "a short history of lines of code (loc) metrics" （页面存档备份，存于互联网档案馆）
延伸阅读
- Li, Luo; Herbsleb, Jim; Shaw, Mary. Forecasting Field Defect Rates Using a Combined Time-based and Metric–based Approach a Case Study of OpenBSD (CMU-ISRI-05-125). Carnegie-Mellon University. May 2005 [2020-01-10]. （原始内容存档于2021-02-24）.
- McGraw, Gary. From the Ground Up: The DIMACS Software Security Workshop. IEEE Security & Privacy. March–April 2003, 1 (2): 59–66. doi:10.1109/MSECP.2003.1193213.
- Park, Robert E.; et al. Software Size Measurement: A Framework for Counting Source Statements. Technical Report CMU/SEI-92-TR-20. [2020-01-10]. （原始内容存档于2013-06-26）.
外部链接
- Definitions of Practical Source Lines of Code Resource Standard Metrics (RSM) defines "effective lines of code" as a realistics code metric independent of programming style.
- Effective Lines of Code eLOC Metrics for popular Open Source Software Linux Kernel 2.6.17, Firefox, Apache HTTPD, MySQL, PHP using RSM.
- Wheeler, David A. SLOCCount. [2003-08-12]. （原始内容存档于2021-02-24）.
- Wheeler, David A. Counting Source Lines of Code (SLOC). June 2001 [2003-08-12]. （原始内容存档于2021-01-26）.
- Tanenbaum, Andrew S. Modern Operating Systems (2nd ed.). Prentice Hall. ISBN 0-13-092641-8.
- Howard Dahdah. Tanenbaum outlines his vision for a grandma-proof OS. 2007-01-24 [2007-01-29]. （原始内容存档于2007-01-27）.
- C. M. Lott: Metrics collection tools for C and C++ Source Code （页面存档备份，存于互联网档案馆）
- Folklore.org: Macintosh Stories: -2000 Lines Of Code （页面存档备份，存于互联网档案馆）