ソースコード行

ソースコード行数( SLOC ) は、コード行数( LOC )とも呼ばれ、プログラムのソースコードのテキスト内の行数を数えることによってコンピュータプログラムのサイズを測定するために使用されるソフトウェアメトリックです。 SLOC は通常、プログラムの開発に必要な労力の量を予測するだけでなく、ソフトウェアが作成された後の プログラミングの生産性や保守性を見積もるために使用されます。

多くの有用な比較は、プロジェクト内のコード行数の桁数のみを基準にしています。コード行数を使用して 10,000 行のプロジェクトと 100,000 行のプロジェクトを比較することは、20,000 行のプロジェクトと 21,000 行のプロジェクトを比較する場合よりもはるかに有用です。コード行数を正確に測定する方法については議論の余地がありますが、桁違いの差異はソフトウェアの複雑さや工数の明確な指標になり得ます。

SLOC の測定には、物理​​ SLOC (LOC) と論理 SLOC (LLOC) の 2 つの主要な種類があります。これら 2 つの測定の具体的な定義はさまざまですが、最も一般的な物理 SLOC の定義は、コメント行を除いたプログラムのソース コードのテキストの行数です。^[1]

論理 SLOC は実行可能な「ステートメント」の数を測定しようとしますが、その特定の定義は特定のコンピュータ言語に結び付けられています ( Cのようなプログラミング言語の 1 つの簡単な論理 SLOC 測定は、ステートメント終了のセミコロンの数です)。物理 SLOC を測定するツールを作成する方がはるかに簡単で、物理 SLOC の定義は説明が簡単です。ただし、物理 SLOC 測定は、論理 SLOC よりも、論理的に無関係なフォーマットとスタイル規則の影響を受けやすいです。ただし、SLOC 測定は定義なしで示されることが多く、論理 SLOC は物理 SLOC と大きく異なることがよくあります。

SLOC を決定する際に発生する曖昧さの例として、次の C コード スニペットを検討してください。

for ( i = 0 ; i < 100 ; i ++ ) printf ( "hello" ); /* これは何行のコードですか? */         

この例では、次のようになります。

• 1物理コード行（LOC）、
• 2 論理コード行 (LLOC) ( for文とprintf文)
• コメント行 1 行。

プログラマーとコーディング標準に応じて、上記のコード「行」は複数の別々の行に記述される可能性があります。

/* このコードは何行あるでしょうか? */ 
for ( i = 0 ; i < 100 ; i ++ ) { printf ( "hello" ); }       

    

この例では、次のようになります。

• 4 物理コード行 (LOC): 中括弧の配置作業は見積もられるべきでしょうか?
• 2 論理コード行 (LLOC): 非ステートメント行を記述するすべての作業はどうなるのでしょうか?
• 1 つのコメント行: ツールは、コメントの配置に関係なく、すべてのコードとコメントを考慮する必要があります。

「論理的」および「物理的」な SLOC 値にも、さまざまな定義が多数存在します。Robert E. Park ( Software Engineering Institute在籍時) らは、プロジェクトで使用される SLOC 測定を注意深く説明および定義できるように、SLOC 値を定義するフレームワークを開発しました。たとえば、ほとんどのソフトウェア システムはコードを再利用するため、測定値を報告するときには、どの再利用コード (ある場合) を含めるかを決定することが重要です。

SLOC が測定基準として導入された当時、最も一般的に使用されていた言語、たとえばFORTRANやアセンブリ言語は行指向言語でした。これらの言語は、パンチカードがプログラミングのデータ入力の主な形式であった時代に開発されました。1 枚のパンチカードは通常、1 行のコードを表します。これは、簡単に数えられる 1 つの個別のオブジェクトでした。これはプログラマーの目に見える出力であったため、コード行をプログラマーの生産性の尺度として数えることは、管理者にとって理にかなっており、「カード イメージ」などと呼んでもいました。今日、最も一般的に使用されているコンピューター言語では、書式設定にかなりの余地があります。テキスト行は 80 列または 96 列に制限されなくなり、1 行のテキストが 1 行のコードに対応する必要もなくなりました。

SLOC の尺度は、特にその誤用方法が時々あるという点で、多少議論の的になっています。実験により、労力は SLOC と高い相関関係にあることが繰り返し確認されています^[要出典]。つまり、SLOC 値が大きいプログラムほど開発に時間がかかります。したがって、SLOC は労力の見積もりに効果的です。ただし、機能性は SLOC とあまり相関していません。熟練した開発者は、同じ機能性をはるかに少ないコードで開発できる場合があります。そのため、SLOC の少ないプログラムが、他の同様のプログラムよりも機能性が高い場合があります。SLOC を生産性の尺度としてカウントすることには注意が必要です。開発者は、数行しか開発していなくても、最終的により多くの行を作成する (そして一般的により多くの労力を費やす) 開発者よりも機能性の点ではるかに生産的であるためです。優秀な開発者は、複数のコード モジュールを 1 つのモジュールにマージしてシステムを改善することがありますが、コードを削除するため生産性がマイナスのように見えます。さらに、経験の浅い開発者はコードの重複に頼ることが多いですが、これはバグが発生しやすく、保守コストも高くなるため強く推奨されませんが、SLOC が高くなります。

SLOC カウントでは、言語を正規化するために調整係数が適用されない限り、異なる言語で書かれたプログラムを比較する際にさらに精度の問題が生じます。さまざまなコンピュータ言語は、簡潔さと明瞭さをさまざまな方法でバランスさせています。極端な例として、ほとんどのアセンブリ言語では、 APLで数文字を実行するのと同じタスクを実行するために、数百行のコードが必要になります。次の例は、 BASIC、C、およびCOBOL (特に冗長な言語として知られている) で書かれた「hello world」プログラムの比較を示しています。

SLOC メトリックの比較でますます一般的になっているもう 1 つの問題は、自動生成されたコードと手書きのコードの違いです。最新のソフトウェア ツールには、マウスを数回クリックするだけで膨大な量のコードを自動生成する機能が搭載されていることがよくあります。たとえば、グラフィカル ユーザー インターフェイス ビルダーは、アイコンをワークスペースにドラッグするだけで、グラフィカル コントロール要素のすべてのソース コードを自動的に生成します。このコードの作成にかかる作業は、たとえばデバイス ドライバーの作成に必要な作業とは比較になりません。同様に、手動でコーディングされたカスタム 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万を超える物理SLOCが含まれていたと報告しました。彼はまた、従来の独自の方法で開発されていた場合、約8,000人年の開発労力と10億ドル以上のコスト(2000年の米ドル)が必要だっただろうと推測しました。

同様の調査が、後にDebian GNU/Linuxバージョン 2.2 (別名「Potato」) に対して行われました。このオペレーティング システムは、2000 年 8 月に最初にリリースされました。この調査では、Debian GNU/Linux 2.2 には 5,500 万を超える SLOC が含まれており、従来の独自の方法で開発した場合、開発に 14,005 人年と 19 億ドルの費用がかかることが判明しました。その後、使用されたツールを実行すると、Debian の次のリリースには 1 億 400 万 SLOC があり、2005 年現在^[update]、最新のリリースには 2 億 1,300 万を超える SLOC が含まれる予定です。

1. カウントの自動化の範囲: コード行は物理的なエンティティであるため、カウント プロセスを自動化することで、手動でカウントする作業を簡単に排除できます。プログラム内の LOC をカウントするための小さなユーティリティが開発される可能性があります。ただし、特定の言語用に開発された論理コード カウント ユーティリティは、言語間の構文および構造の違いにより、他の言語には使用できません。ただし、数十の言語をカウントする物理的な LOC カウンターが開発されています。
2. 直感的なメトリック: コード行は、目で確認でき、その影響を視覚化できるため、ソフトウェアのサイズを測定するための直感的なメトリックとして機能します。ファンクション ポイントは、物理的なエンティティとして想像できない客観的なメトリックであると言われています。これは、論理的な空間にのみ存在します。このように、LOC は、経験の浅いプログラマーにとってソフトウェアのサイズを表すのに役立ちます。
3. 普遍的な尺度：LOC尺度はソフトウェアの初期の頃から存在しています。^[15]そのため、他のどのサイズ尺度よりも多くのLOCデータが利用可能であると主張することもできます。

1. 説明責任の欠如: コード行数測定には、いくつかの根本的な問題があります。一部の人^{[誰? ]}は、コーディング フェーズの結果のみを使用してプロジェクトの生産性を測定するのは役に立たないと考えています。コーディング フェーズは通常、全体の作業量の 30% から 35% しか占めません。^{[引用が必要]}
2. 機能性との結合性の欠如: 実験^{[誰が? ]}では、労力は LOC と高い相関関係にあるのに対し、機能性は LOC とあまり相関関係にないことが繰り返し確認されています。つまり、熟練した開発者は、はるかに少ないコードで同じ機能を開発できる可能性があるため、LOC の少ないプログラムが、他の同様のプログラムよりも多くの機能性を発揮する可能性があります。特に、LOC は個人の生産性の指標としては不十分です。数行しか開発しない開発者でも、より多くの行数を作成する開発者よりも生産性が高い場合があるためです。さらに、冗長なコードを削除してクリーンな状態に保つための「メソッドの抽出」などの適切なリファクタリングにより、コード行数は大幅に削減されます。
3. 見積もりへの悪影響: ポイント 1 で示した事実により、コード行に基づく見積もりは、おそらく間違ったものになる可能性があります。
4. 開発者の経験: 特定のロジックの実装は、開発者の経験レベルによって異なります。したがって、コードの行数は人によって異なります。経験豊富な開発者は、同じ言語を使用していても、比較的経験の浅い他の開発者よりも少ないコード行数で特定の機能を実装する場合があります。
5. 言語の違い: 同じ機能 (画面、レポート、データベース) を提供する 2 つのアプリケーションを考えてみましょう。アプリケーションの 1 つは C++ で記述され、もう 1 つは COBOL などの言語で記述されています。ファンクション ポイントの数はまったく同じですが、アプリケーションのさまざまな側面は​​異なります。アプリケーションの開発に必要なコード行数は、当然同じではありません。その結果、アプリケーションの開発に必要な労力 (ファンクション ポイントあたりの時間数) も異なります。コード行数とは異なり、ファンクション ポイントの数は一定です。
6. GUIツールの登場: Visual Basicなどの GUI ベースのプログラミング言語とツールの登場により、プログラマーは比較的少ないコードで高度な機能を実現できるようになりました。たとえば、ウィンドウを作成してボタンを描画するプログラムを作成する代わりに、GUI ツールを使用するユーザーは、ドラッグ アンド ドロップなどのマウス操作を使用してコンポーネントをワークスペースに配置できます。GUI ツールによって自動的に生成されるコードは、通常、LOC 測定方法を使用する場合は考慮されません。このため、言語間でばらつきが生じます。ある言語では 1 行のコード (またはコードなし) で実行できる同じタスクが、別の言語では数行のコードを必要とする場合があります。
7. 複数言語の問題: 今日のソフトウェア シナリオでは、ソフトウェアは複数の言語で開発されることがよくあります。複雑さと要件に応じて、複数の言語が使用されることもよくあります。この場合、システムの統合後に欠陥を特定の言語に帰属させることができないため、生産性と欠陥率の追跡とレポートが深刻な問題を引き起こします。この場合、機能ポイントがサイズの最適な尺度であることが際立っています。
8. カウント基準の欠如: コード行が何であるかの標準的な定義はありません。コメントはカウントされますか? データ宣言は含まれていますか? ステートメントが複数行にまたがる場合はどうなりますか? – これらはよく生じる質問です。SEI や IEEE などの組織はカウントを標準化するためのガイドラインをいくつか発行していますが、毎年新しい言語が導入されているため、これを実践するのは困難です。
9. 心理学: 生産性がコード行数で測定されるプログラマーは、不必要に冗長なコードを書く動機を持ちます。経営陣がコード行数に注目するほど、プログラマーはコードを不必要に複雑に拡張する動機が強くなります。これは望ましくありません。複雑性が増すと、メンテナンスのコストが増加し、バグ修正に必要な労力も増加する可能性があるからです。

PBS のドキュメンタリー「Triumph of the Nerds」で、マイクロソフトの幹部であるスティーブ・バルマー氏は、コードの行数を数える手法を批判しました。

IBM にはソフトウェアの宗教があり、K-LOC を数えなければならないとされています。K-LOC は 1,000 行のコードです。どのくらいの規模のプロジェクトですか? ああ、これは 10K-LOC のプロジェクトです。これは 20K-LOC です。これは 50K-LOC です。そして IBM は、これを私たちの給料の受け取り方に関する宗教にしようとしていました。私たちはOS/2でいくら儲け、彼らはいくら儲けたか。あなたは何 K-LOC をやったか? そして私たちは彼らを説得しようとし続けました。もし開発者が良いアイデアを持っていて、20K-LOC ではなく 4K-LOC で何かを成し遂げられるなら、私たちの給料は少なくてもいいのでしょうか? なぜなら、彼はもっと小さくて速いものを、より少ない K-LOC で作ったからです。K-LOC、K-LOC、それが方法論です。うわー! とにかく、このこと全体を考えるといつも背筋が凍ります。

コンピュータ歴史博物館によると、 Apple の開発者であるビル・アトキンソンは1982 年にこの方法に問題を発見しました。

1982年にLisaチームがソフトウェアの完成に向けて邁進していたとき、プロジェクトマネージャはプログラマーに、書いたコードの行数を報告するフォームを毎週提出するよう要求し始めた。ビル・アトキンソンは、それは馬鹿げていると思った。QuickDrawの領域計算ルーチンを6倍高速化し、2000行短くした週については、フォームに「-2000」と記入した。さらに数週間後、マネージャは彼にフォームへの記入を要求しなくなり、彼は喜んでそれに従った。^{[16] [17]}

• ソフトウェア開発の労力見積もり
• 見積（プロジェクト管理）
• ソフトウェアエンジニアリングにおけるコスト見積り

• Li, Luo、Herbsleb, Jim、Shaw, Mary (2005 年 5 月)。時間ベースとメトリックベースの組み合わせによるフィールド欠陥率の予測 - OpenBSD のケース スタディ (CMU-ISRI-05-125)。カーネギーメロン大学。
• McGraw, Gary (2003年3 月～ 4 月)。「From the Ground Up: DIMACS ソフトウェア セキュリティ ワークショップ」。IEEEセキュリティ & プライバシー。1 (2): 59– 66。doi :10.1109/MSECP.2003.1193213。
• Park, Robert E.; et al. (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. Modern Operating Systems (第 2 版)。Prentice Hall。ISBN 0-13-092641-8。 
• Howard Dahdah (2007-01-24). 「Tanenbaum がおばあちゃんでも使える OS のビジョンを説明」。2007-01-27 にオリジナルからアーカイブ。2007-01-29に取得。
• CM Lott. 「C および C++ ソースコード用のメトリック収集ツール」。2020 年 6 月 19 日時点のオリジナルよりアーカイブ。
• Folklore.org: Macintosh ストーリー: -2000 行のコード