測定方法
複数の有用な比較において、プロジェクトのコード行数の桁数のみを用いることができます。10,000行のプロジェクトと100,000行のプロジェクトをコード行数で比較する方が、20,000行のプロジェクトと21,000行のプロジェクトを比較するよりもはるかに有用です。コード行数をどのように測定するかについては議論の余地がありますが、桁違いの差は、ソフトウェアの複雑さや開発工数を明確に示す指標となり得ます。
SLOC の測定には、物理的 SLOC (LOC) と論理的 SLOC (LLOC) の 2 つの主要なタイプがあります。これらの 2 つの測定の具体的な定義は様々ですが、物理的 SLOC の最も一般的な定義は、プログラムのソース コードのテキスト内の行数をカウントし、コメント行を除外することです。[ 1 ]
論理SLOCは実行可能な「ステートメント」の数を測定しようとするものですが、その具体的な定義は特定のプログラミング言語に依存しています（C言語のようなプログラミング言語における単純な論理SLOCの指標の一つは、ステートメントを終了させるセミコロンの数です）。物理SLOCを測定するツールを作成する方がはるかに簡単で、物理SLOCの定義も説明しやすいです。ただし、物理SLOCの指標は、論理的に無関係な書式やスタイルの慣例に対して、論理SLOCよりも敏感です。しかし、SLOCの指標は定義を示さずに提示されることが多く、論理SLOCは物理SLOCと大きく異なる場合がよくあります。
SLOCを決定する際に遭遇する曖昧さの例として、以下のC言語コードの断片を考えてみましょう。
for ( int i = 0 ; i < 100 ; i ++ ) printf ( "hello" ); /* 100 個の挨拶を表示 */
この例では、次のようになります。
- 1 物理的なコード行 (LOC)、
- 2 論理行のコード (LLOC) ( forステートメントとprintfステートメント)、
- コメント行1行。
プログラマーやコーディング規約によっては、上記の「1行」のコードは複数の別々の行に記述される可能性があります。
/* 100個の挨拶を表示する */ for ( int i = 0 ; i < 100 ; i ++ ) { printf ( "hello" ); }この例では、次のようになります。
- 物理的なコード行数 (LOC) が 4 行の場合、中括弧を配置する作業は見積もりが必要ですか？
- 論理的に2行のコード（LLOC）：ステートメント以外の行を書く作業はどうなるのでしょうか？
- 1行のコメント: ツールは、コメントの位置に関係なく、すべてのコードとコメントを考慮する必要があります。
「論理的」SLOC値と「物理的」SLOC値でさえ、さまざまな定義が存在する可能性があります。ロバート・E・パーク氏（ソフトウェアエンジニアリング研究所在籍時）らは、プロジェクトで使用されるSLOC測定方法を丁寧に説明・定義できるように、SLOC値を定義するためのフレームワークを開発しました。例えば、ほとんどのソフトウェアシステムはコードを再利用しており、どの再利用コードを含めるか（もしあれば）を判断することは、測定結果を報告する際に重要です。
起源
SLOCが指標として導入された当時、FORTRANやアセンブリ言語など、最も一般的に使用されていた言語は行指向言語でした。これらの言語は、パンチカードがプログラミングにおけるデータ入力の主な手段であった時代に開発されました。パンチカード1枚は通常、コードの1行を表していました。それは簡単に数えられる独立したオブジェクトでした。プログラマーの目に見える出力であったため、マネージャーはプログラマーの生産性の指標としてコード行数を数えることに抵抗がなく、「カードイメージ」などと呼んでいました。今日では、最も一般的に使用されているコンピュータ言語は、フォーマットに関してより多くの自由度を提供しています。テキスト行はもはや80列または96列に制限されておらず、テキスト1行が必ずしもコードの1行に対応するとは限りません。
SLOC対策の利用
SLOC（ソースコード行数）の測定は、特に誤用されることがあるため、やや議論の余地があります。実験では、労力とSLOCの相関関係が高いことが繰り返し確認されています。つまり、SLOCの値が大きいプログラムほど開発に時間がかかります。したがって、SLOCは労力の推定に有効です。しかし、機能性とSLOCの相関関係はそれほど高くありません。熟練した開発者は、はるかに少ないコードで同じ機能を開発できるため、SLOCが少ないプログラムでも、類似のプログラムよりも多くの機能を発揮する場合があります。SLOCを生産性の指標として用いることには注意点があります。開発者は数行しかコードを作成しなくても、より多くの行を作成する（そして一般的に労力を多く費やす）開発者よりも、機能性の面で遥かに生産性が高い場合があるからです。優秀な開発者は、複数のコードモジュールを1つのモジュールに統合することでシステムを改善しますが、コードを削除するため、生産性が低下したように見えることがあります。さらに、経験の浅い開発者は、バグが発生しやすく保守コストも高くなるため強く推奨されないコードの重複に陥りがちですが、結果としてSLOCは高くなります。
SLOC カウントは、言語を正規化するための調整係数を適用しない限り、異なる言語で書かれたプログラムを比較する際に、さらなる精度上の問題を引き起こします。さまざまなコンピュータ言語は、簡潔さと明瞭さのバランスを異なる方法で取っています。極端な例として、ほとんどのアセンブリ言語では、 APLで数文字で済む同じタスクを実行するのに数百行のコードが必要になります。次の例は、BASIC、C、およびCOBOL (特に冗長な言語として知られています)で書かれた「ハローワールド」プログラムの比較を示しています。
SLOCメトリクスを比較する際に、ますます一般的になっているもう一つの問題は、自動生成されたコードと手書きのコードの違いです。最新のソフトウェアツールは、マウスを数回クリックするだけで膨大な量のコードを自動生成できる機能を備えていることがよくあります。例えば、グラフィカルユーザーインターフェースビルダーは、アイコンをワークスペースにドラッグするだけで、グラフィカルコントロール要素のすべてのソースコードを自動的に生成します。このコードの作成にかかる作業は、例えばデバイスドライバを作成するのに必要な作業とは、合理的に比較できません。同様に、手書きでコーディングされたカスタムGUIクラスは、単純なデバイスドライバよりも簡単に多くの労力を要する可能性があります。これが、このメトリクスの欠点です。
SLOC を入力パラメータとして使用するコスト、スケジュール、および労力の見積もりモデルはいくつかあり、Barry Boehmらによる広く使用されている Constructive Cost Model ( COCOMO ) シリーズ、PRICE Systems True S、および Galorath のSEER-SEMなどが含まれます。これらのモデルは優れた予測能力を示していますが、入力される見積もり (特に SLOC の見積もり) の精度に依存します。多くの[ 2 ]は、機能性の尺度として SLOC の代わりにファンクション ポイントを使用することを提唱していますが、ファンクション ポイントは SLOC と高い相関があり (自動的に測定できない) るため、これは普遍的に受け入れられている見解ではありません。
例
Vincent Maraia氏によると[ 3 ] 、 MicrosoftのWindows NT製品ラインのさまざまなオペレーティングシステムのSLOC値は次のとおりです。
David A. Wheeler は、 Linux オペレーティングシステムのRed Hatディストリビューションを調査し、Red Hat Linuxバージョン 7.1 [ 6 ] (2001 年 4 月にリリース) には 3,000 万行を超える物理的な 1 行コードが含まれていると報告しました。また、従来の独自の方法で開発されていた場合、約 8,000 人年の開発努力が必要となり、10 億ドル以上 (2000 年米ドル換算) の費用がかかっただろうと推測しました。
同様の調査が後にDebian GNU/Linuxバージョン2.2（通称「ポテト」）でも行われました。このオペレーティングシステムは2000年8月に最初にリリースされました。この調査では、Debian GNU/Linux 2.2には5500万行を超えるSLOCが含まれており、従来の独自方式で開発した場合、14,005人年と19億米ドルの開発費用が必要だったことが判明しました。使用されたツールの後続の実行では、次のDebianリリースには1億400万行のSLOCがあり、2005年時点で最新リリースには、2億1300万以上のSLOCが含まれる予定です。
ユーティリティ
利点
- カウントの自動化の可能性：コード行は物理的な実体であるため、カウント処理を自動化することで、手動でのカウント作業を容易に排除できます。プログラム内のコード行数をカウントするための小型ユーティリティを開発することも可能です。ただし、特定の言語向けに開発された論理コードカウントユーティリティは、言語間の構文や構造の違いにより、他の言語には使用できません。一方、数十種類の言語に対応した物理的なコード行数カウンターは既に開発されています。
- 直感的な指標：コード行数は、ソフトウェアのサイズを測る直感的な指標として用いられます。なぜなら、コード行数は目に見えるものであり、その影響を視覚化できるからです。ファンクションポイントは、より客観的な指標であり、物理的な実体として捉えることはできず、論理空間にのみ存在します。このように、コード行数は、経験の浅いプログラマーにとってソフトウェアのサイズを表現する上で便利な指標となります。
- 普遍的な尺度：LOC尺度はソフトウェアの初期の頃から存在しています。[ 15 ]そのため、LOCデータは他のどのサイズ尺度よりも多く入手可能であると言えるでしょう。
デメリット
- 説明責任の欠如：コード行数による測定には、いくつかの根本的な問題があります。プロジェクトの生産性を、全体の作業量のわずか30～35％を占めるコーディング段階の結果のみで測定するのは適切ではないと考える人もいます。
- 機能との整合性の欠如：実験では繰り返し、労力はLOCと高い相関関係にあるものの、機能はLOCとそれほど相関関係にないことが確認されています。つまり、熟練した開発者ははるかに少ないコードで同じ機能を開発できるため、LOCが少ないプログラムの方が、類似の別のプログラムよりも多くの機能を発揮する可能性があります。特に、LOCは個人の生産性を測る指標としては不適切です。なぜなら、数行しか開発しない開発者でも、より多くのコードを作成する開発者よりも生産性が高い場合があるからです。さらに、冗長なコードを削除してコードをクリーンに保つための「メソッドの抽出」などの適切なリファクタリングによって、コード行数は大抵削減されます。
- 見積もりへの悪影響: ポイント #1 で述べた事実により、コード行数に基づく見積もりは、あらゆる可能性において悪影響を及ぼす可能性があります。
- 開発者の経験：特定のロジックの実装方法は、開発者の経験レベルによって異なります。そのため、コード行数も人によって異なります。経験豊富な開発者は、同じ言語を使用しても、経験の浅い開発者よりも少ないコード行数で特定の機能を実装できる場合があります。
- 言語の違い：同じ機能（画面、レポート、データベース）を提供する2つのアプリケーションを考えてみましょう。一方のアプリケーションはC++で記述され、もう一方はCOBOLのような言語で記述されています。ファンクションポイントの数は全く同じですが、アプリケーションの機能は異なります。アプリケーションの開発に必要なコード行数は当然異なります。結果として、アプリケーションの開発に必要な労力（ファンクションポイントあたりの時間）も異なります。コード行数とは異なり、ファンクションポイントの数は一定です。
- GUIツールの登場： Visual BasicなどのGUIベースのプログラミング言語とツールの登場により、プログラマーは比較的少ないコードで高度な機能を実現できるようになりました。たとえば、ウィンドウを作成してボタンを描画するプログラムを書く代わりに、GUIツールを使用するユーザーは、ドラッグアンドドロップなどのマウス操作でワークスペース上にコンポーネントを配置できます。GUIツールによって自動的に生成されるコードは、通常、LOC測定方法を使用する際には考慮されません。このため、言語によってばらつきが生じます。ある言語では1行のコード（またはコードなし）で実行できるタスクが、別の言語では数行のコードを必要とする場合があります。
- 複数の言語における問題点：今日のソフトウェア開発環境では、ソフトウェアはしばしば複数の言語で開発されます。複雑さや要件に応じて、複数の言語が使用されることも少なくありません。このような場合、生産性や欠陥率の追跡と報告は深刻な問題となります。なぜなら、システム統合後に欠陥を特定の言語に帰属させることができないからです。このような状況において、ファンクションポイントは規模の指標として最適です。
- カウント基準の欠如：コード行とは何かという標準的な定義が存在しない。コメントはカウントされるのか？データ宣言は含まれるのか？ステートメントが複数行にわたる場合はどうなるのか？――これらは頻繁に発生する疑問である。SEIやIEEEといった組織はカウントの標準化を目指してガイドラインを発表しているものの、毎年新しい言語が登場する状況では、それらを実際に適用するのは困難である。
- 心理学的に言えば、生産性をコード行数で評価されるプログラマーは、不必要に冗長なコードを書くインセンティブを持つようになる。経営陣がコード行数に注目すればするほど、プログラマーは不必要な複雑さをコードに盛り込むようになる。これは望ましくない。なぜなら、複雑さが増すと、保守コストの増加やバグ修正に必要な労力の増加につながるからだ。
PBSのドキュメンタリー番組「オタクの勝利」の中で、後にマイクロソフトの幹部となるスティーブ・バルマーは、コードの行数を数えるという方法を批判した。
IBMでは、ソフトウェア開発においてK-LOC（1,000行のコード）を数えることが一種の宗教のようなもので、K-LOCは1,000行のコードを意味します。プロジェクトの規模はどれくらいですか？ああ、10,000行くらいのプロジェクトです。これは20,000行、これは50,000行です。IBMは、私たちの給料の決め方を、まるで宗教のように決めつけようとしていました。OS /2でどれだけ稼いだか、どれだけやったか。何K-LOC書いたか。私たちは、開発者が良いアイデアを持っていて、20,000行ではなく4,000行で何かを成し遂げた場合、給料を減らすべきではないかと説得し続けていました。なぜなら、彼はより小さく、より速く、より少ないK-LOCを作ったからです。K-LOC、K-LOC、それが方法論です。ああ！とにかく、そのことを考えるといつも背中が縮れてしまいます。
コンピュータ歴史博物館によると、アップルの開発者であるビル・アトキンソンは1982年にこのやり方に問題があることに気づいた。
1982年にLisaチームがソフトウェアの最終化に取り組んでいたとき、プロジェクトマネージャーはプログラマーに毎週、書いたコードの行数を報告するフォームを提出するように要求し始めた。ビル・アトキンソンはそれを馬鹿げていると思った。QuickDrawの領域計算ルーチンを6倍速く、2000行短く書き直した週、彼はフォームに「-2000」と記入した。数週間後、マネージャーは彼にフォームの記入を求めなくなり、彼は喜んでそれに従った。[ 16 ] [ 17 ]
注記
- ↑オペレーティングシステムと通常バンドルされているアプリケーションだけでなく、iLifeスイート全体が含まれる可能性があります。
参考文献
- ↑ Vu Nguyen; Sophia Deeds-Rubin; Thomas Tan; Barry Boehm (2007)、「SLOCカウント標準（PDF）」、南カリフォルニア大学システム・ソフトウェア工学センター
- ↑ IFPUG「ファンクションポイントを使用するメリットを定量化する」
- 1 2 3 4 5 6 「Windows のコード行数は？」 Knowing.NET。2005 年 12 月 6 日。2010年8 月 30 日に取得。これは、情報源としてヴィンセント・マライアの著書『ザ・ビルド・マスター』を挙げている。
- ↑ 「Windows XP のコード行数は？」。マイクロソフト。2011 年 1 月 11 日。2022年 2 月 26 日にオリジナルからアーカイブされました。
- ↑ 「Windowsの歴史 - Microsoft Windows」。2012年9月21日。2012年9月21日のオリジナルからアーカイブ。2021年3月26日取得。
- 1 2 David A. Wheeler (2001-06-30). 「1ギガバック以上: GNU/Linuxのサイズを推定する」。
- ↑ゴンサレス＝バラオナ、ヘスス M.ミゲル・A・オルトゥーニョ・ペレス。ペドロ・デ・ラス・ヘラス・キロス。ホセ・センテノ・ゴンサレス。ビセンテ・マテラン・オリベラ。「ジャガイモを数える: Debian 2.2 のサイズ」。debian.org。2008 年 5 月 3 日にオリジナルからアーカイブされました。2003 年 8 月 12 日に取得。
- 1 2 3 4 5 Robles, Gregorio. "Debian Counting" . 2013-03-14 のオリジナルからアーカイブ済み。2007-02-16 に取得。
- ↑ Debian 7.0 は 2013 年 5 月にリリースされました。この数字は、David A. Wheeler が公開したデータと同じソフトウェア方法を使用して、Debian 7.0 となるコードベースを使用して 2012 年 2 月 13 日に公開された推定値です。James Bromberger。「Debian Wheezy: US$19 Billion. Your price... FREE!」 。 2014 年 2 月 23 日にオリジナルからアーカイブされました。2014年 2 月 7 日に取得。
- ↑ジョブズ、スティーブ（2006年8月）。「WWDC 2006からのライブ：スティーブ・ジョブズの基調講演」 。 2007年2月16日取得。8600
万行のソースコードが、まったく新しいアーキテクチャ上で問題なく動作するように移植されました。
- ↑ Thorsten Leemhuis (2009-12-03). "Linux 2.6.32 の新機能" . 2013-12-19 のオリジナルからアーカイブ済み。2009-12-24 に取得。
- ↑ Greg Kroah-Hartman、Jonathan Corbet、Amanda McPherson (2012年4月)。「Linuxカーネル開発：そのスピード、開発者、開発内容、スポンサー」。Linux Foundation 。 2012年4月10日取得。
- ↑ Thorsten Leemhuis (2012-10-01). "概要、展望、統計 - H Open: ニュースと特集" . 2013-12-19 のオリジナルからアーカイブ済み。
- ↑ "Linux-Kernel durchbrricht die 20-Millionen-Zeilen-Marke"。 2015 年 6 月 30 日。
- ↑ IFPUG「コード行数（loc）メトリクスの短い歴史」
- ↑ 「 MacPaintとQuickDrawのソースコード」.CHM.2010-07-18.2021-04-15に取得。
- ↑ "Folklore.org: -2000 Lines Of Code" . www.folklore.org . 2021年4月15日取得.
さらに読む
- Li, Luo; Herbsleb, Jim; Shaw, Mary (2005年5月).時間ベースとメトリックベースのアプローチを組み合わせたフィールド欠陥率の予測：OpenBSDのケーススタディ（CMU-ISRI-05-125）。カーネギーメロン大学。
- McGraw, Gary (2003年3月～4月) 「基礎から：DIMACSソフトウェアセキュリティワークショップ」 IEEE Security & Privacy 1 ( 2): 59–66 . doi : 10.1109/MSECP.2003.1193213 .
- Park, Robert E.; 他 (1992年8月31日) 「ソフトウェアサイズ測定：ソースステートメントをカウントするためのフレームワーク」技術報告書 CMU/SEI-92-TR-20。
外部リンク
- 実用的なソースコード行数の定義 リソース標準メトリクス (RSM) は、「有効なコード行数」をプログラミングスタイルに依存しない現実的なコードメトリクスとして定義します。
- RSMを使用して、Linuxカーネル2.6.17、Firefox、Apache HTTPD、MySQL、PHPといった人気のあるオープンソースソフトウェアの有効コード行数（eLOC）メトリクスを測定します。
- Wheeler, David A. "SLOCCount" . 2003年8月12日取得。
- Wheeler, David A. (2001年6月). 「ソースコード行数（SLOC）のカウント」 . 2003年8月12日取得.
- Tanenbaum, Andrew S. 『現代オペレーティングシステム』（第2版）。Prentice Hall。ISBN 0-13-092641-8。
- ハワード・ダダ（2007年1月24日）。「タネンバウムが祖母でも使えるOSの構想を概説」 。 2007年1月27日のオリジナルからアーカイブ。 2007年1月29日閲覧。
- CM Lott。「CおよびC++ソースコードのためのメトリクス収集ツール」 。2020年6月19日にオリジナルからアーカイブされました。
- Folklore.org: Macintosh ストーリー: -2000 行のコード
