ソースコード行

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

測定方法

複数の有用な比較は、プロジェクト内のコード行数の桁数のみを基準とします。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" ); /* これは何行のコードでしょうか? */

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

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

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

/* このコードは何行ありますか? */ for ( int i = 0 ; i < 100 ; i ++ ) { printf ( "hello" ); }

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

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

「論理的」および「物理的」SLOC値でさえ、多種多様な定義を持つ場合があります。Robert E. Park氏（ソフトウェア工学研究所在籍時）らは、SLOC値を定義するためのフレームワークを開発しました。これにより、プロジェクトで使用されるSLOC指標を慎重に説明および定義することが可能になります。例えば、ほとんどのソフトウェアシステムはコードを再利用するため、指標を報告する際には、どのコードを（もしあれば）再利用するかを判断することが重要です。

起源

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

SLOC対策の使用

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

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

ベーシックCコボル 
「こんにちは、世界」と印刷する
#include <stdio.h>int main () { printf ( "hello, world \n " ); }
識別部.プログラム ID . hello .手続き部. 「hello, world」と表示.戻る.プログラム終了hello .
コード行数: 1 (空白なし)コード行数: 4 (空白を除く)コード行数: 6 (空白を除く)

SLOCメトリックの比較において、自動生成コードと手書きコードの違いがますます一般的になりつつある問題の一つです。現代のソフトウェアツールは、マウスを数回クリックするだけで膨大な量のコードを自動生成する機能を備えていることがよくあります。例えば、グラフィカルユーザーインターフェースビルダーは、アイコンをワークスペースにドラッグするだけで、グラフィカルコントロール要素のソースコードをすべて自動的に生成します。このコードの作成にかかる労力は、例えばデバイスドライバーの作成に必要な労力とは比べものになりません。同様に、手動でコーディングされたカスタムGUIクラスは、単純なデバイスドライバーよりも要求が厳しい場合が多く、これがこのメトリックの欠点となっています。

SLOCを入力パラメータとして使用するコスト、スケジュール、工数見積モデルはいくつかある。その中には、広く使用されているBarry Boehmらによる一連のConstructive Cost Model（ COCOMO）モデル、PRICE Systems True S、GalorathのSEER-SEMなどがある。これらのモデルは優れた予測力を示しているが、その精度は入力される推定値（特にSLOC推定値）に依存している。多くの[ 2 ]は、機能性の尺度としてSLOCではなく機能ポイントの使用を提唱しているが、機能ポイントはSLOCと高い相関関係にある（そして自動的に測定できない）ため、これは普遍的な見解ではない。

例

ヴィンセント・マライア[ 3 ]によれば、マイクロソフトのWindows NT製品ラインにおける様々なオペレーティングシステムのSLOC値は次のとおりです。

年オペレーティング·システムSLOC（百万）
1993ウィンドウズNT3.14～5 [ 3 ]
1994ウィンドウズNT3.57～8 [ 3 ]
1996ウィンドウズNT4.011～12 [ 3 ]
2000ウィンドウズ200029以上[ 3 ]
2001ウィンドウズXP45 [ 4 ] [ 5 ]
2003Windows Server 200350 [ 3 ]

デビッド・A・ウィーラーは、Red Hat Linuxオペレーティングシステムのディストリビューションを研究し、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年時点では最新リリースで2億1,300万SLOC以上が含まれる予定であることが報告されています。

年オペレーティング·システムSLOC（百万）
2000デビアン 2.255～59 [ 7 ] [ 8 ]
2002デビアン 3.0104 [ 8 ]
2005デビアン 3.1215 [ 8 ]
2007デビアン 4.0283 [ 8 ]
2009デビアン 5.0324 [ 8 ]
2012デビアン 7.0419 [ 9 ]
2009オープンソラリス9.7
フリーBSD8.8
2005Mac OS X 10.486 [ 10 ] [ n 1 ]
1991Linuxカーネル0.010.010239
2001Linuxカーネル2.4.22.4 [ 6 ]
2003Linuxカーネル2.6.05.2
2009Linuxカーネル2.6.2911.0
2009Linuxカーネル2.6.3212.6 [ 11 ]
2010Linuxカーネル2.6.3513.5 [ 12 ]
2012Linuxカーネル3.615.9 [ 13 ]
2015年6月30日Linuxカーネル4.2以前20.2 [ 14 ]

ユーティリティ

利点

  1. カウントの自動化の可能性：コード行は物理的な実体であるため、カウントプロセスを自動化することで、手作業によるカウント作業を容易に排除できます。プログラム内のLOCをカウントするための小規模なユーティリティを開発することは可能です。しかし、特定の言語向けに開発された論理的なコードカウントユーティリティは、言語間の構文や構造の違いにより、他の言語には使用できません。一方、数十の言語に対応する物理的なLOCカウンタが開発されています。
  2. 直感的な指標：コード行数は、目に見える形でその影響を視覚化できるため、ソフトウェアの規模を測る直感的な指標として機能します。ファンクションポイントは、物理的な実体として捉えられず、論理空間にのみ存在する客観的な指標であると言われています。そのため、コード行数は、経験の浅いプログラマーにとってソフトウェアの規模を表すのに便利です。
  3. 普遍的な尺度：LOC尺度はソフトウェアの初期の頃から存在してきました。[ 15 ]そのため、他のどのサイズ尺度よりも多くのLOCデータが利用可能であると言えます。

デメリット

  1. 説明責任の欠如：コード行数による測定には根本的な問題がいくつか存在します。コーディング段階の成果のみを用いてプロジェクトの生産性を測定するのは有用ではないと考える人もいます。コーディング段階は通常、全体の作業量の30%から35%に過ぎません。
  2. 機能性との凝集性の欠如：実験では、労力はLOCと高い相関関係にある一方、機能性はLOCとそれほど相関していないことが繰り返し確認されています。つまり、熟練した開発者は同じ機能をはるかに少ないコード量で開発できる場合があり、LOCの少ないプログラムが他の類似プログラムよりも多くの機能性を発揮する可能性があるということです。特に、LOCは個人の生産性を測る指標としては適切ではありません。なぜなら、数行しか開発しない開発者でも、より多くのコード行を開発する開発者よりも生産性が高い場合があるからです。さらに、「メソッド抽出」などの適切なリファクタリングによって冗長なコードを削除し、クリーンな状態にすることで、コード行数を大幅に削減できます。
  3. 見積りへの悪影響: ポイント 1 で示した事実により、コード行数に基づく見積りは、間違った結果になる可能性が高くなります。
  4. 開発者の経験：特定のロジックの実装は、開発者の経験レベルによって異なります。したがって、コード行数も人によって異なります。同じ言語を使用していても、経験豊富な開発者は、比較的経験の浅い開発者よりも少ないコード行数で特定の機能を実装できる場合があります。
  5. 言語の違い：同じ機能（画面、レポート、データベース）を提供する2つのアプリケーションを考えてみましょう。一方のアプリケーションはC++で記述され、もう一方のアプリケーションは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 は 1000 行のコードだ、というものです。どれくらいの規模のプロジェクトですか? ああ、これは 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 ]

参照

注記

  1. ^オペレーティング システムと通常バンドルされているアプリケーションだけでなく、iLife スイート全体が含まれる可能性があります。

参考文献

  1. ^ Vu Nguyen、Sophia Deeds-Rubin、Thomas Tan、Barry Boehm (2007)、「SLOCカウント標準」 (PDF)、南カリフォルニア大学システム・ソフトウェア工学センター
  2. ^ IFPUG「ファンクションポイント使用の利点の定量化」
  3. ^ a b c d e f「Windowsのコード行数は？」 Knowing.NET、2005年12月6日。 2010年8月30日閲覧。ここでは、情報源としてVincent Maraia のThe Build Masterが引用されています。
  4. ^ 「Windows XPのコード行数は？」 Microsoft、2011年1月11日。 2022年2月26日時点のオリジナルよりアーカイブ。
  5. ^ 「Windowsの歴史 - Microsoft Windows」 2012年9月21日. 2012年9月21日時点のオリジナルよりアーカイブ。2021年3月26日閲覧。
  6. ^ a b David A. Wheeler (2001-06-30). 「ギガバック以上の価値：GNU/Linuxの規模を推定する」 .
  7. ^ゴンサレス＝バラオナ、ヘスス M.;ミゲル・A・オルトゥーニョ・ペレス。ペドロ・デ・ラス・ヘラス・キロス。ホセ・センテノ・ゴンサレス。ビセンテ・マテラン・オリベラ。「ジャガイモを数える: Debian 2.2 のサイズ」。debian.org。2008 年 5 月 3 日にオリジナルからアーカイブされました。2003 年 8 月 12 日に取得。
  8. ^ a b c d e Robles, Gregorio. 「Debian Counting」 . 2013年3月14日時点のオリジナルよりアーカイブ。2007年2月16日閲覧。
  9. ^ Debian 7.0は2013年5月にリリースされました。この数字は、2012年2月13日に発表された推定値であり、Debian 7.0となるコードベースを用いて、David A. Wheelerが発表したデータと同じソフトウェア手法を用いて算出されています。James Bromberger. 「Debian Wheezy: US$19 Billion. Your price... FREE!」 。 2014年2月23日時点のオリジナルよりアーカイブ。 2014年2月7日閲覧。
  10. ^ Jobs, Steve (2006年8月). 「Live from WWDC 2006: Steve Jobs Keynote」. 2007年2月16日閲覧。8,600万行に及ぶソースコードが、全く新しいアーキテクチャ上で問題なく動作するように移植された。
  11. ^ Thorsten Leemhuis (2009年12月3日). 「Linux 2.6.32の新機能」 . 2013年12月19日時点のオリジナルよりアーカイブ。 2009年12月24日閲覧。
  12. ^ Greg Kroah-Hartman、Jonathan Corbet、Amanda McPherson (2012年4月). 「Linuxカーネル開発：進捗状況、開発担当者、開発内容、スポンサー」 . The Linux Foundation . 2012年4月10日閲覧。
  13. ^ Thorsten Leemhuis (2012年10月1日). 「要約、展望、統計 - The H Open: ニュースと特集」 . 2013年12月19日時点のオリジナルよりアーカイブ。
  14. ^ "Linux-Kernel durchbrricht die 20-Millionen-Zeilen-Marke" . 2015 年 6 月 30 日。
  15. ^ IFPUG「コード行数（loc）メトリクスの短い歴史」
  16. ^ 「MacPaintとQuickDrawのソースコード」 CHM 2010年7月18日. 2021年4月15日閲覧。
  17. ^ 「Folklore.org: -2000 Lines Of Code」 . www.folklore.org . 2021年4月15日閲覧。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Source_lines_of_code&oldid=1333761234」より取得