16オクテオンを超えるNPathの複雑さは現実的ですか？または、ツールを壊しましたか？

PHPMD（http://phpmd.org/）を使用してPHPコードの大部分（1153行）を測定したところ、コードのNPathの複雑さは16244818757303403077832757824であることがわかりました。

それは私にとってクレイジーに大きな数字のように見え、おそらくPHPMDが何らかの形で壊れていることを示唆しています。人間によって書かれたコードの一部がこのような高いNPath複雑さを持つことさえ可能ですか？循環的複雑度は351です。

おそらく重要な2つの詳細-

1. これはHTMLと混合した手続き型コードであり、PHPMDはオブジェクト指向コードのみを測定します。これを回避するために、単一の関数を使用してファイル全体をクラスにラップしました。これは、ファイルの使用方法を表しています。

2. このファイルは一連のネストされたswitchステートメントで構成されており、その中には多数のif..elseステートメントがあります。したがって、確かにかなり複雑です。

編集

PHPMDが私に嘘をついているかどうかを疑っていないことを明確にしたい。私は、コードがひどい混乱であることを知っています、私はただ、どんなコードでも本当にそんなに悪いことが可能かどうか疑問に思います。答えはイエスのようです、それは非常に可能です。

これは完全に可能です。各10ケースの35のスイッチケースコンストラクトがあると仮定します。これにより、各スイッチが次々に発生するときに、350の大まかな循環的複雑度が得られます。最初のスイッチは10個のパスを提供します。2番目のスイッチは別の10個の独立したパスを提供するため、ここまで10・10個のパスがあります。3番目のスイッチを使用すると、10・10・10 =10³パスが得られ、合計10 ³⁵パスが得られるまで続きます。これは、1.6・10 ²⁸パスの結果よりもさらに高くなります。これは、おそらく分岐要因が異なるためであり、コードを通るパスの数を減らすネストされた制御フローステートメントが原因です。

特定の循環的複雑度cの最悪の場合のシナリオとして、最大2 ^c個の非循環パスをコードに含めることができます（ここでは2 ³⁵¹ = 4.6・10 ¹⁰⁵）。

ツールの判断は明確です。扱っているコードは複雑で、テストできず、維持できない混乱です。それをより小さな独立した関数に分割し、繰り返しを抽象化することを検討してください。たとえば、PHPスクリプトのメインロジックからHTML生成を分離できます。

この説明によれば、NPathの複雑度は循環的複雑度において指数関数的です。

単純なifステートメントを使用すると、これらのステートメントが2つある場合、2つのステートメント条件の4つの可能なtrue / falseの組み合わせに対応するコードを経由する4つのルートになります。別のifステートメントを追加すると、8が得られます。

言い換えると、すべての循環的およびNPathの複雑さがif文の長いリストに由来する場合、等式はになりますNPath = 2^cyclomatic。それをあなたの数字と比較すると、2 ^ 351 = 4.6 * 10 ^ 105、あなたが報告したNPathの複雑さよりもはるかに高い。

実際には不可能なパスのカウントを避けるためにPHPMDがどれだけするかわかりません（たとえば、2つの相互に排他的な条件が両方ともtrueと評価される）。おそらく手動分析では、多くのパスが実際には不可能であることが明らかになるため、コードはNPathメトリックを増大させる方法で記述されます。上記を続けるために、351個のifステートメントのリストがあり、実際に1つだけが入力されたことを確認できた場合、if ... elseステートメントのチェーンに変換して、NPathの複雑さを4.6 * 10から減らすことができます^ 105から353。

しかし、質問の情報だけで、その種の単純化がPHPMDによってどれだけ行われるか、または既に行われているのかがわからないため、その数は現実的です。