原始碼行數 📖 Wikipedia

許多軟體上的比較都只和專案中原始碼行數的数量级有關。用原始碼行數來比較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? */

上例中有：

• 1行的實體原始碼行數（LOC）,
• 2行的邏輯原始碼行數（LLOC）（For迴圈及printf指令）
• 1行註解

依照程式設計者及程式設計風格的不同，上述一行實體原始碼行數的程式可以寫成以下多行的程式：

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

此例中有

• 4行的實體原始碼行數（LOC）：但放括號的工時需要估計進來嗎？
• 2行的邏輯原始碼行數（LLOC）：看不到重排非敘述程式碼的影響
• 1行註解

甚至是「實體」及「邏輯」的原始碼行數都有許多不同的定義。罗伯特·E·帕克（在他還在軟體工程研究所（英语：Software Engineering Institute）時）等人開發了定義SLOC值的一個框架，讓人可以謹慎的說明及定義其專案中用到的SLOC定義及量測方式。例如，大部份軟體會有代碼複用，在回報量測結果時，如何決定是否要包括代碼複用內容就很重要。

人們剛開始用原始碼行數來量度軟體長度時，當時最常用的語言（像是Fortran及汇编语言）都是行導向的程式語言。當時打孔卡是輸入程式的主要方式。一張打孔卡對應一行程式，打孔卡是一張一張的，要計算數量很方便。打孔卡也是程式開發者有形的產出，因此管理者利用計算打孔卡數量來計算程式開發者的生產力是相當合理的。現今最常使用的程式語言在格式上的限制不多，一行的字元數也不止是80個字或是96個字，而一行的文字不一定對應一行的程式碼。

用原始碼行數來做為程式相關屬性的量度，有些會有些爭議。根據多次的實驗，已確認原始碼行數和開發者所花的工作量高度相關^{[來源請求]}，SLOC越大的程式，開發需要花費的時間及工作量也比較多，因此SLOC若用來估計開發者花的心力，是相當有效的。不過SLOC和機能的相關性很低，熟練的程式設計者可能可以用較少的程式碼達到相同的機能，因此有可能SLOC較短的程式，其機能甚至有可能比（其他程式設計師所寫）SLOC較長的程式還要多。用SLOC來度量程式設計者的生產力不一定合適，因為有可能程式設計師只用少少幾行程式，達到的機能比其他程式設計師的許多行程式更多（其他程式設計師也花了較多的心力）。好的程式設計者會將有重複程式的模組整合成一個模組，提昇了程式的品質，但以SLOC的角度來看，反而讓SLOC減少了。而且，有經驗的程式設計者往往會負責最困難的模組，因此看起來不像其他程式設計者一樣的「有生產力」。甚至，沒有經驗的程式設計者往往會有代码重复的情形，一般而言不鼓勵代码重复，因為很不容易維護，很容易有錯，但是會有較多的SLOC。

若用SLOC比較不同程式語言寫的程式，除非有針對不同語言的特性進行正規化，不然其準確度就更低了。各種的计算机语言都設法在簡潔及清楚這兩方面來取捨，有些強調簡潔，有些則強調清楚。以極端的例子來說，汇编语言會需要上百行的程式，來完成APL語言幾個字即可完成的工作。以下是C语言及COBOL所寫的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來計算程式設計者的努力時，另一個常見的問題是人工寫的程式以及自動產生程式的差異。許多現代的軟體工具都可以在滑鼠點選一些設定，或是擺放物件之後，自動生成一大段的程式。例如只要將一些圖案移到工作區，圖形使用者介面產生器（英语：graphical user interface builder）就會自動產生對應控件的大量程式。這個工作量完全不能和寫設備驅動程式的工作量相比。但兩者產生的程式碼長度可能差異不大，這也是用SLOC來計算的缺點。

目前有許多成本、時程及工作量估計的模型，會用SLOC為輸入引數，包括巴里·勃姆（英语：Barry Boehm）等人建立，廣為使用的构造性成本模型（COCOMO）、PRICE系統（英语：PRICE Systems）、True S及Galorath的SEER-SEM（英语：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億美金。

1. 可以自動化計算：因為原始碼行數是程式的實體特質，可以用計算行數的程式來取代人工的行數計算。有許多小的程式可以計算軟體的原始碼行數，不過因為各語言的語法及結構特性不同，針對一種語言計算邏輯原始碼行數的程式可能無法計算其他語言的邏輯原始碼行數。若是要計算實體原始碼行數，已有可以適用於數十種語言的軟體。
2. 符合直覺的度量：原始碼行數是符合直覺的軟體度量標準，易於計算。也有研究者認為用功能點來度量軟體，不過功能點不是程式的實體特質，是邏輯上的概念。而原始碼行數沒有這類問題，就算是經歷不多的程式設計師也可以用原始碼行數來量測軟體大小。
3. 無所不在的度量方式：自從軟體開發的最早期開始，就已經出現原始碼行數的計算^[9]。因此，可以說，原始碼行數的資料會比其他軟體度量方式的資料會多很多。

1. 無法反映實際的工作量。用原始碼行數來計算軟體開發的生產力，有些基本層面的問題。有些研究者認為不能只用編寫程式階段產生的成果來估算專案的產出，一般而言，編寫程式階段只佔整體的30%至35%。
2. 缺乏有關功能凝聚力的資訊：軟體開發者付出的心力可能和原始碼行數的相關性較高，但其程式的機能性和原始碼行數的關係較小。有經驗的程式設計者可以用較短的程式碼達到相同的功能。甚至，一些較熟練的軟體開發者，會用重構的方式，設計調整程式，去除多餘的程式，程式會變的較精簡，也比較理想，但以原始碼行數來看，看不到這方面的貢獻。
3. 心理學上的問題：若程式設計者的產出是用原始碼行數來估算，難免他會調整程式寫法，讓相同機能的程式可以有較多行數的原始碼。

在公共广播电视公司的記錄片《Triumph of the Nerds（英语：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減少了？這是我們的方法論。

• KLOC /ˈkeɪlɒk/ KAY-lok：一千行程式碼
  • KDLOC：一千行已交付的程式碼
  • KSLOC：一千行原始碼
• MLOC：一百萬行程式碼
• GLOC：十億行程式碼

• 軟體開發工作量預估
• 預估 (專案管理)（英语：Estimation (project management)）
• 軟體工程的成本預估（英语：Cost estimation in software engineering）
• 軟體大小預估（英语：Software sizing）

• 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 （页面存档备份，存于互联网档案馆）