コード内の制御フローの深い入れ子は、研究された問題ですか？

私は同僚に、深いレベルの制御フローがコードの可読性に有害であると主張しました。

関連するスタックオーバーフローの質問/software/52685/if-you-need-more-than-3-levels-of-indentation-youre-screwedからの例：

for(int i=0; i<10; ++i){
  Object val = repeat(i, someVar);
  if(val.value > 3){
    switch(val.item){
      case DOG:
        if(mProcess){
          outputToUser(val);
          doMoreThings(val, mMoreThingDoer);
          if(mRepurpose){
            addExample(val);
          }
          // and so on, and so on...

ほとんどの場合と同様に、このトピックに関する意見を見つけるのは簡単です。

しかし、誰かがそれ以上に貢献できるかどうか疑問に思っています。

たとえば、問題に関連する実際の調査が行われたことがありますか？

それとも、「Xのほうが好き」を超えた他の議論をすることはできますか？

coding-style

— user50849
ソース

インデントのレベル数を減らす方法はたくさんあります。早期復帰はその一つです。

— ロバートハーベイ

「権威による証明」が容認できる場合は、マイクロソフトのコードコンプリート（第2版）の関連資料を使用できます。IIRCは、Sec。19.4（その点を超えると、理解の明確さは失われます）。

— hardmath 2013

スコープのすべてのレベルで、コードの機能を正しく理解するために頭に入れておく必要のある追加事項が追加されます。人間の作業記憶はそれほど大きくありません。また、「複数のこと」を行うコードの単体テストの複雑さも考慮してください。

すばやくグーグルすると、いくつかの調査が行われたことがわかります。たとえば、このペーパーでは、バグ率を最小限に抑えるコードの循環的複雑性の価値があることを示しています。

浅いシグモイドグラフ

深いネストは、すべての点で分岐しない限り問題ないでしょう。つまり、例のように、多くのネストされた条件を上に持つことはおそらく問題ありません。これは、本質的に1つの条件であり、単に接続詞として書かれていないからです。

OTOH以下のswitchステートメントが大きく、重大な分岐を含む場合は、 'you're screwed'節が適用される場合があります。

— 9000
ソース