はじめに

今更という感じではありますが、
以前私の所属していたプロジェクトでもLOCを測って〜という話が挙がったので、
あらためてブログの記事にしてまとめておくことにしました。
（結局それを何かしらの指標値に使ったりなどはしていませんが；；）

LOCとは

Lines of codesの略で、ソースコードの行数を指します。
SLOC（Source lines of codes）ということもあります。
また、1000行単位で表すKLOC（Kilo lines of codes）という表現をすることもあります。

「ステップ数」と同じ意味で、プログラムの規模感を表す際によく利用します。

物理LOCと論理LOC

LOCの中でも、物理LOCと論理LOCと呼ばれるものとに分かれます。

物理LOC

物理LOCは、コードの行数そのものを指します。
テキストエディタなどでファイルを開き、表示されている行数がそのままLOCになります。

論理LOC

論理LOCは、物理LOCから空の行やコメントだけの行を除いたものを指します。
アプリケーションが動くためのプログラムの行数を数えたものになります。

LOCをプログラムの規模や生産性を図る際に使うメリット・デメリット

すでに多くの方が指摘されていますが、LOCを指標に使うのは良し悪しです。

メリット

（とくに物理LOCの場合）簡単に算出することができる

デメリット

論理LOCの算出時に決める除外する行の定義がずれると差分が生まれる
非効率的なプログラムを書いた場合に行数が膨れ上がることがある

たとえば、ソフトウェアの開発規模を測る際、
LOCと1人あたりの生産性、月単価で開発コストを算出することが可能です。
プログラムの行数という一見非常に客観的な指標値を用いているようにも思われますが、
実際には上記であげたデメリットの通りで、非常に主観的な値になりうるのです。

おわりに

個人的にはLOCでプログラムの規模測定やスケジュール策定を行うのは「イマドキではない」と考えてはいますが、
簡易的に規模感を測る必要があったり、なかなか確固たる指標がないがために採用することは往々にしてあるでしょう。
そのような際、明確な基準を持って測ることとある程度の差が出ることを考慮に入れ、
このLOCによる見積もりを実施する必要があると感じました。