代码线

代码（ SLOC ）的源行，也称为代码线（ LOC ），是一种软件度量标准，用于通过计算程序源代码文本中的行数来测量计算机程序的大小。 SLOC通常用于预测开发程序所需的精力，以及一旦生产软件，可以估算编程生产率或可维护性。

测量方法

许多有用的比较仅涉及项目中代码线的数量级。使用代码线将10,000线项目与100,000线项目进行比较要比将20,000线项目与21,000线项目进行比较要有用得多。虽然这是有争议的如何测量代码线的问题，但是数量级的差异可能是软件复杂性或工时的明确指标。

SLOC措施有两种主要类型：物理SLOC（LOC）和逻辑SLOC（LLOC）。这两个度量的特定定义各不相同，但是物理sloc的最常见定义是程序源代码（不包括评论行）的文本中的一条线。

逻辑SLOC试图测量可执行“语句”的数量，但是它们的特定定义与特定的计算机语言相关联（类似于C的编程语言的一个简单的逻辑SLOC度量是语句终止的半元素的数量）。创建测量物理sloc的工具要容易得多，而物理SLOC定义更容易解释。但是，与逻辑SLOC相比，物理SLOC措施对逻辑上无关的格式和样式惯例更为敏感。但是，通常在没有定义的情况下陈述了SLOC措施，逻辑SLOC通常与物理SLOC显著不同。

将C代码的这个片段视为确定SLOC时遇到的歧义的示例：

for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */

在此示例中，我们有：

• 1个物理线（LOC），
• 2条代码的逻辑行（LLOC）（用于语句和printf语句），
• 1条评论行。

根据程序员和编码标准，上述代码的“行”可以写在许多单独的行上：

/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
    printf("hello");
}

在此示例中，我们有：

• 4个物理线的代码（LOC）：放置牙套是否有效估计？
• 2逻辑线（LLOC）：所有编写非说明线的工作呢？
• 1评论行：工具必须考虑到所有代码和评论，而不论评论放置如何。

即使是“逻辑”和“物理” SLOC值也可以具有大量不同的定义。罗伯特·E·帕克（Robert E. Park）（在软件工程学院的同时）和其他人开发了一个用于定义SLOC值的框架，以使人们能够仔细解释和定义项目中使用的SLOC度量。例如，大多数软件系统重复使用代码，并确定在报告度量时（如果有）重复使用的代码（如果有）很重要。

起源

在将SLOC作为度量引入时，最常用的语言（例如Fortran和Assembly语言）是面向线条的语言。这些语言是在打孔卡是用于编程数据输入的主要形式时开发的。一张打孔卡通常代表一行代码。这是一个容易计数的离散对象。这是程序员的可见输出，因此对于管理人员来说，将代码线计算为对程序员的生产力的测量，甚至是指“卡片图像”。如今，最常用的计算机语言允许格式化更多的余地。文本行不再限于80或96列，一行文本不一定要对应于一行代码。

使用SLOC措施

SLOC措施有些争议，尤其是在有时被滥用的方式上。实验反复证实，努力与SLOC高度相关，即具有较大SLOC值的程序需要更多的时间来开发。因此，SLOC可以有效地估算努力。但是，功能与SLOC的相关性不大：熟练的开发人员可能能够使用较少的代码来开发相同的功能，因此，SLOC较少的一个程序可能比另一个类似程序显示出更多的功能。将SLOC算作生产力度量有其警告，因为开发人员只能开发几行，但在功能方面的生产力要比最终创建更多线条（并且通常花费更多的精力）的开发人员的生产力要高得多。好的开发人员可以将多个代码模块合并到一个模块中，改善系统，但由于删除代码而似乎具有负面的生产力。此外，经验不足的开发人员通常会诉诸代码重复，因为它更容易容易出现错误，并且维护的昂贵，但会导致更高的SLOC。

SLOC计数在比较用不同语言编写的程序进行比较时表现出进一步的准确性问题，除非将调整因素应用于标准化语言。各种计算机语言以不同的方式平衡简洁和清晰度；作为一个极端的例子，大多数汇编语言都需要数百行代码来执行与APL中的几个字符相同的任务。下面的示例显示了用基本， C和Cobol （以详细词而闻名的语言）编写的“ Hello World”程序的比较。

PRINT "hello, world"

#include <stdio.h>
int main() {
    printf("hello, world\n");
}

      identification division.
      program-id. hello .
      procedure division.
      display "hello, world"
      goback .
      end program hello .

比较SLOC指标的另一个日益普遍的问题是自动生成和手写代码之间的差异。现代软件工具通常具有自动化大量代码的能力，只需单击鼠标。例如，图形用户界面构建器仅通过将图标拖到工作空间来自动生成图形控制元素的所有源代码。例如，无法合理地将创建此代码的工作与编写设备驱动程序所需的工作进行比较。同样，与简单的设备驱动程序相比，手工编码的自定义GUI类可能更苛刻。因此，这个指标的缺点。

使用SLOC作为输入参数的几种成本，时间表和工作估计模型，包括Barry Boehm等人的广泛使用的建设性成本模型（ Cocomo ）系列模型， Price Systems True S和Galorath的Seer-Sem 。尽管这些模型表现出良好的预测能力，但它们仅与给它们的估计值（尤其是SLOC估计值）一样好。许多人主张使用功能点而不是SLOC作为功能的量度，但是由于功能点与SLOC高度相关（并且无法自动测量），这不是普遍持有的视图。

例子

根据Vincent Maraia的说法， Microsoft Windows NT产品线中各种操作系统的SLOC值如下：

大卫·A·惠勒（David A. Wheeler）研究了Linux操作系统的红帽分布，并报导Red Hat Linux版本7.1（2001年4月发布）包含超过3000万个实体SLOC。他还推断出，如果它是由常规专有方式开发的，它将需要大约8,000人的发展工作，并且将花费超过10亿美元（2000年的美元）。

后来对Debian GNU/Linux版本2.2（也称为“马铃薯”）进行了类似的研究；该操作系统最初于2000年8月发布。这项研究发现，Debian GNU/Linux 2.2包括超过5500万SLOC，如果以传统专有方式开发，则需要14,005人年，并且需要花费19亿美元才能开发。后来使用的工具报告说，以下发布Debian的SLOC具有1.04亿个SLOC，截至2005年，最新版本将包括超过2.13亿个SLOC。

公用事业

优点

1. 自动化自动化的范围：由于代码线是物理实体，因此可以通过自动计数过程轻松消除手动计数工作。可以开发小型实用程序来计算程序中的LOC。但是，由于语言之间的句法和结构差异，为其他语言开发的逻辑代码计数实用程序不能用于其他语言。但是，已经产生了物理位置计数器，这些计数器计算了数十种语言。
2. 直观的指标：代码行是一种直观的度量，用于测量软件的大小，因为它可以看到，并且可以看到它的效果。据说功能点更像是一个客观的度量标准，无法被认为是物理实体，它仅存在于逻辑空间中。这样，LOC派上用场表达经验水平较低的程序员中的软件大小。
3. 无处不在的措施：自软件最早的几天以来，LOC措施就已经存在。因此，可以说比任何其他尺寸度量都可以使用更多的LOC数据。

缺点

1. 缺乏问责制：编码线量的措施遭受了一些基本问题。有些人认为仅使用编码阶段的结果来衡量项目的生产率没有用，这通常仅占整体工作的30％至35％。
2. 功能缺乏凝聚力：尽管实验反复证实，尽管努力与LOC高度相关，但功能与LOC的相关性较小。也就是说，熟练的开发人员可能能够使用较少的代码来开发相同的功能，因此与另一个类似程序相比，一个LOC更少的程序可能表现出更多的功能。特别是，LOC是个人的生产力量差，因为只开发几行的开发人员可能仍然比开发人员创建更多代码行的生产力更高- 甚至更多：一些良好的重构，例如“提取方法”，以摆脱。冗余代码并保持清洁将主要减少代码线。
3. 对估计的不利影响：由于点＃1下提出的事实，基于代码行的估计可能会对错误产生不利影响。
4. 开发人员的经验：根据开发人员的经验水平的实施，实施特定的逻辑有所不同。因此，代码线数的数量因人而异。经验丰富的开发人员可能会在代码行中实现某些功能，而不是其他经验相对较少的开发人员，尽管他们使用相同的语言。
5. 语言差异：考虑提供相同功能的两个应用程序（屏幕，报告，数据库）。其中一个应用程序用C ++编写，另一个用COBOL等语言编写的应用程序编写。功能点的数量将完全相同，但是应用程序的各个方面将有所不同。开发应用程序所需的代码行当然不会相同。结果，开发应用程序所需的努力将是不同的（每个功能点小时）。与代码线不同，功能点的数量将保持恒定。
6. GUI工具的出现：随着基于GUI的编程语言和Visual Basic等工具的出现，程序员可以编写相对较少的代码并实现高水平的功能。例如，使用GUI工具的用户可以使用拖放和其他鼠标操作将组件放置在工作空间上。使用LOC测量方法时，通常不会考虑由GUI工具自动生成的代码。这会导致语言之间的变化；可以在一种语言中以一行代码（或根本没有代码）完成的同一任务可能需要另一种语言中的几行代码。
7. 多种语言的问题：在当今的软件方案中，软件通常以多种语言开发。通常，根据复杂性和要求，使用多种语言。在这种情况下，跟踪和报告生产率和缺陷率在这种情况下构成了一个严重的问题，因为缺陷不能归因于系统集成后的特定语言。在这种情况下，功能点是最佳尺寸的最佳度量。
8. 缺乏计数标准：没有什么是代码行的标准定义。评论数吗？包括数据声明吗？如果语句延伸到几行，会发生什么？ - 这些是经常出现的问题。尽管SEI和IEEE等组织已经发布了一些准则，以试图进行标准化的计数，但很难将其付诸实践，尤其是面对每年引入较新的语言。
9. 心理学：以代码行测量生产力的程序员将有动力编写不必要的冗长代码。管理越重点是代码行，程序员必须以不需要的复杂性来扩展其代码。这是不可取的，因为提高的复杂性可以导致维护成本增加，并增加了错误修复所需的精力。

在书呆子的PBS纪录片《胜利》中，微软执行史蒂夫·鲍尔默（Steve Ballmer）批评使用计数行的使用线：

在IBM中，软件中有一种宗教，您必须对K-loc进行计数，而K-Loc是一千行代码。项目有多大？哦，这是一个10k-Loc的项目。这是一个20k-Locer。这是50k-locs。 IBM希望将其成为关于我们如何获得报酬的宗教。我们从OS/2赚了多少钱，他们做了多少钱。您做了多少个K-locs？我们一直试图说服他们 - 嘿，如果有的话 - 开发人员有一个好主意，他可以在4k-locs而不是20k-locs中完成某件事，我们应该赚更多的钱吗？因为他做了更小，更快，k-loc的东西。 k-locs，k-locs，这就是方法论。啊!无论如何，这总是让我的背部想到整个事情。

根据计算机历史博物馆的说法，苹果开发商比尔·阿特金森（Bill Atkinson）在1982年发现了这种做法的问题：

当Lisa团队在1982年推动最终确定其软件时，项目经理开始要求程序员提交每周的表格报告，以报告他们编写的代码行数。比尔·阿特金森（Bill Atkinson）认为这很愚蠢。在他重写QuickDraw的区域计算例程的一周中，他的六倍，而2000行短，他将“ -2000”放在表格上。再过几周后，经理们停止要求他填写表格，他很乐意遵守。

也可以看看

• 软件开发工作估算
• 估计（项目管理）
• 软件工程的成本估算