ちょっと考える機会があったので、世界の常識かもしれませんが一応メモとして書いておきます。LoCとかは意外と奥が深い。基本情報処理技術者等で出てくるかもしれませんが。。

まずはLoCから。

こちら参考に。

物理LoC

＞テキストファイルとしての総行数

ですって。これを使ってれば認識ずれはない、と思われます。でも、一般的にコード行数（ステップ数）として話をするときに、物理LoCを使うことってほとんどないんじゃないかなと思います。

論理LoC

＞物理LOCから空行やコメント行などを除いた行数

ですって。ここの”など”に深遠な意味があるようですね。

＞スペースやタブだけの行をカウントする
＞2つの命令が書かれた行は2行としてカウントする
＞括弧だけの行をカウントしない
＞連続した空行は1行としてカウントする

ここら辺がズレの原因、とのことです。どれもわかるなぁ。どこまで厳密に「論理的な」行数とするかによりますよね。

・スペースやタブだけの行をカウントしない
・2つの命令が書かれた行も1行としてカウントする
・括弧だけの行をカウントしない
・連続した空行は0行としてカウントする

ぐらいが僕の直感には合います。参照元に書いてある、客観的な指標としてはつかえない、が事実なんでしょうね…。これも書いてありますが、ツールを統一するとかはベストプラクティスかもしれませんね。

ステートメント

ステートメント数、ってあんまり言わないようですね。あと、文脈によっても変わりそう。ステートメントカバレッジ（C0）の文脈では、条件文は含まないようですが、「ifステートメント」という呼び方もあるようなので、if文がステートメントではない、は正しくなさそうです。

僕自身が調べた背景はコードカバレッジの文脈なので、条件文含まない、で調べました。

ブランチ

ブランチで検索すると、バージョン管理の方が出てきますね。ブランチカバレッジの文脈でいうと、分岐の枝分かれの数の総数がブランチカバレッジの母数になるようです。僕は分岐の数かな、とちょっと思っていたので、勘違いしてました。まぁカバレッジ計測するには、確かに枝分かれの総数を数えないとだめですよね。

あと、elseがないケースはどうなるんだろうとも思いましたが、処理をしないという分岐先の動きがあると考えるとカウントするのが正しい気がします。

おしまい。