この項目では、ソフトウェアに関する指標について説明しています。その他の用法については「LOC (曖昧さ回避)」をご覧ください。

この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2018年11月） 独自研究が含まれているおそれがあります。（2018年11月） 出典検索?: "LOC" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL

LOCは、lines of codeの略で、ソフトウェアの規模を表す指標のひとつ。ソースコードの行数を意味する。何の行数かを明確に示すため、SLOC (source lines of code) ということもある。

テキストファイルとしての行数を物理LOC (physical LOC) というが、これをそのまま使うことは少ない。空行（改行など空白だけの行）やコメント行（コメントと空白だけの行）は除く、2つの命令が書かれた行は2行と数える、括弧だけの行を除くなどの換算をした行数を論理LOC (logical LOC) といい、通常はこちらを使う。ただし、細かい規則にはさまざまな流儀がある。物理行数であればwc -lなど汎用の行数を数えるツールで、論理行数であれば汎用のテキスト処理ツールを利用するなどして、作業を自動化できる。

問題点

LOCには以下のような問題がある。

• ソフトウェアのサイズを表すが、機能の量や開発工数の結びつくものではない。また書き方次第で簡単に水増しできる。
• 優れた開発者や開発チームは少ないLOCで多くの価値を提供するが、未熟なチームだとLOCは多くとも実現する機能は少なく、質は悪くなる。そのためLOCと開発コストを紐付けることはできない。
• プログラミング言語の記述にはある程度の自由度があり、まったく動作が等しいプログラムであってもさまざまな記述ができる。これは特に、C言語の流れを汲む自由度の高い言語で著しい。
• 同じまたは類似の処理をコピー&ペーストすればLOCは簡単に増える。マクロ化、関数化、クラス化などすれば、ソースコードは読みやすく保守しやすくなるが、LOCは減る。
• 同じ問題を解決するためにもさまざまな解決法があり、無駄な処理をしたり効率の悪いアルゴリズムを使ったりすればLOCは増えることが多い。
• 同じ処理内容であっても、プログラミング言語の種類によって必要なLOCは大きく変わる。たとえば、C言語を基準にすると、COBOLやFORTRANは数倍、アセンブリ言語では十倍以上の行数が必要であることが多い。ただしこれは、ソフトウェア開発のコストの指標としてはむしろ適切な長所であると言える。

このような問題があるため、LOCでソフトウェアの実際の規模を測るのは難しい。そのため、LOCに変わる指標としてファンクションポイント法などが利用されてきている^[1]。

簡単な例

1からnまでの和を計算するC++のプログラムを例に取る。次の標準的なソースコードのLOCは（物理LOC、論理LOCとも）3行である。

int s = 0;
for (int i = 1; i <= n; i++)
    s += i;

コメント行があっても論理LOCは同じ3行である。（物理LOCは4行である）

// 1からnまでの和
int s = 0;
for (int i = 1; i <= n; i++)
    s += i;

次のソースコードは論理LOCが4行だが、処理内容はまったく同じである。

int s = 0;
int i = 1;
for (i = 1; i <= n; i++)
    s += i;

次のソースコードは、同じ結果を出す非常に高速なアルゴリズムで、論理LOCは1行である。

int s = (n + 1) * n / 2;

実際の製品の例

How Many Lines of Code in Windows?, Knowing.NET, (December 06, 2005), http://www.knowing.net/PermaLink,guid,c4bdc793-bbcf-4fff-8167-3eb1f4f4ef99.aspx 2007年10月18日閲覧。  より。

関連項目

• ソフトウェア測定法
• ファンクションポイント法

脚注