コード量とバグ含有率について

コード量とバグ含有量についての考察をしてみた。

一般的に、というか普通に考えてコードの記述量が増すとバグの含有率は増すと
考えていたけども、どうもそれだけではないようだ。

確かに、記述量が増すとタイプミスの発生する確率は高くなる、タイプミスは高級言語であるならば基本的にコンパイラがエラーとして知らせてくれるために早期に間違いを発見しやすく、こちらはバグとしては問題にならないため考慮からはずす。

ただし、プログラムに混入された文字列に対するエラーは通知されないため、こちらは
考慮が必要である。
この場合は固定文字列であるため状態は一つしか持たない。つまり固定文字列のタイプミスに対してエラーチェックは正しい固定文字列との比較であるため単純に実行可能でありバグの解消も容易であると推測される。

ようやく本題で、コンパイルエラーが発生しなかったコードに対する考察である。
コンパイルエラーが発生しなかった場合のコード中のバグの一般数は変数に対する状態の積から状態考慮数の数を引いたものであると規定する。
式：バグ数＝状態数-考慮数
状態とは変数の取りうる値すべてであり、状態考慮数とは変数がある任意の値をとる場合に問題がないことを考慮した数である、これにはさらに変数の状態以外が入り込む場合のブロック処理も考慮にいれることとする。
※考慮しなかった任意の状態値が必ずバグになるとは限らないとの反論がありそうですが、プログラムというものは意図した動作をコンピューターにさせるための命令セットであると考えますので意図しない動作はここでは未知のバグとして取り扱います。

こうして考えてみると状態数に対する考慮数の最大値は
考慮数＝状態数に対する考慮数＋状態外ブロック数＋状態外ブロック数の処理に対する状態数・・・
と考慮数が無限大になることが言える。
ただし、一般的には考慮数≦状態数であるため、実際のプログラムはバグだらけということではありません。

考察結果としてバグの発生を抑えるためには状態外ブロック数を0とするか極小にすること、もしくは状態外ブロック数が収束するようなブロック処理を用いることが必要になる。　
そうすることで　バグ数＝状態数ー考慮数　となり潜在バグの総数も把握しやすい。
これによって閉鎖的なプログラムであればあるほど堅牢なプログラムを構築できると言える。たとえばWebアプリケーションであるならば、IEのみをターゲットにする場合とIEとFireFoxをターゲットにする場合ではIEのみの場合が閉鎖的であり、後者のようにCSSやJavaScriptの両互換性を考慮する必要がないため堅牢なプログラムを構築できる。ここで考慮する必要がないというのはすでに考慮されているという意味である。

結論として「バグ発生を抑えるためには閉鎖的なプログラム構築を行う、つまりInputが少ないプログラムを構築する。」となる。

次に状態数の把握だがこちらは変数の取りうる値の積で近似することとする。
ここでnはロジック内で使用される変数の数と等しくなる。
式：状態数＝（Xn｜Xn-1｜・・・・・｜X1）
ここでXを状態の集合値であらわす、これが状態数の最大値となる。

状態数の近似は以上であるが、実際において状態数を把握するということは考慮を行うということと平行して行う必要がある。
たとえばロジック中に１から３までの状態をとる変数A,B,Cがあるとする。上記式では状態数はA×B×C=２７となる。

しかし、ロジック中に式C=A+Bの記述がある場合はAとBの変数の値が決まればCが決定されるため。つまりAとBの状態積がCとなり
状態数：A×B+（C=A×B）＝１８となる。
このように考慮を行うことで実状態数の把握が可能となる。
この状態数の把握がバグ含有率の基準のひとつといえる。

Javaにおいてtry〜catch構文があるがこれはブロック内の未知の状態を一まとめに考慮した構文でバグの含有率を低下させる反面、バグのトレーサビリティを低下させている、しかしながらこの構文はプログラム作成の現実解と言える。