源代碼行數

**原始碼行數**（Source lines of code）簡稱 **SLOC**，也稱為**程式行數**（lines of code），簡稱 **LOC**，是由計算程式原始碼的行數來估計電腦程式大小的軟體度量。原始碼行數一般會用來預計開發程式需要的人力及時間，若在軟體完成後，也可以用來估計程式開發生產力或可維護性。

## 計算方式

許多軟體上的比較都只和專案中原始碼行數的數量級有關。用原始碼行數來比較 10,000 行原始碼和 100,000 行原始碼的專案，會比比較 20,000 行和 21,000 行的專案要有效很多。有關原始碼行數的計算方式仍有許多不同意見，不過原始碼行數的數量級可以做為軟體複雜度及評估需要人時的一個指標。

原始碼行數計算方式主要可分為兩種：實體原始碼行數（physical SLOC、LOC）及邏輯原始碼行數（logical SLOC、LLOC）。這兩種計算方式的具體定義也有很多種，不過最常用的實體原始碼行數是直接計算不考慮註解時，程式碼的行數。

邏輯原始碼行數設法計算可執行的「敘述」的數量。但具體定義和使用的程式語言有關（若是針對類似 C 語言的程式語言，有一種邏輯原始碼行數的方式就是計算程式碼結尾的分號個數）。要製作工具來計算實體原始碼行數比較容易，也比較容易說明其定義。不過實體原始碼行數會受到一些和邏輯無關的格式及程式風格影響，邏輯原始碼行數比較不會受到格式及程式風格影響。在實務上，計算原始碼行數時不一定會具體寫出其定義，而邏輯原始碼行數和實體原始碼行數之間會有顯著的差異。

以下的 C 語言程式可以用來說明計算原始碼行數的模糊不清之處：

上例中有：

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

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

此例中有

* 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 範例程式的比較：

在使用 SLOC 來計算程式設計者的努力時，另一個常見的問題是人工寫的程式以及自動產生程式的差異。許多現代的軟體工具都可以在滑鼠點選一些設定，或是擺放物件之後，自動生成一大段的程式。例如只要將一些圖案移到工作區，圖形使用者介面產生器就會自動產生對應控制項的大量程式。這個工作量完全不能和寫裝置驅動程式的工作量相比。但兩者產生的程式碼長度可能差異不大，這也是用 SLOC 來計算的缺點。

目前有許多成本、時程及工作量估計的模型，會用 SLOC 為輸入引數，包括巴里・勃姆等人建立，廣為使用的構造性成本模型（COCOMO）、PRICE 系統、True S 及 Galorath 的 SEER-SEM。這些模型的預測能力都很好，但程度會和給模型的輸入資料（尤其是 SLOC 估計值）準確程度有關。有些軟體工程研究者建議用功能點代替 SLOC，不過因為功能點和 SLOC 高度相關，而且無法自動計算，因為各研究者對此論點的看法還沒有共識。

### 舉例

依照 Vincent Maraia 的統計，微軟 Windows NT 中不同時期的作業系統其 SLOC 如下：

針對 Debian2.2 版（Windows NT）以後的作業系統，也有類似的統計，Debian GNU/Linux 2.2 有 55 million SLOC，依傳統私用程式的開發方式，需要 14,005 人年，需要花 190 億美金。

## 評論

### 優點

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

### 缺點

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

在公共廣播電視公司的記錄片《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：十億行程式碼

## 相關條目

* 軟體開發工作量預估
* 預估 (專案管理)
* 軟體工程的成本預估
* 軟體大小預估

## 參考資料

## 延伸閱讀

* 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 （頁面存檔備份，存於網際網路檔案館）