3

ネストが深すぎるコードブロックを含むメソッドから開発者に警告し、混乱を再ファクタリングするように促すカスタムFxCopコード分析ルールを作成しようとしています。

元。私は次の状況を避けようとしています：

if(condition)
{
   foreach(var item in items)
   {
       if(anotherCondition)
       {
           for(var product in item.Products)
           {
               // even more nested statement blocks...
           }
       }
   }
}

VisitBlock(Block block)ブロックの深さをカウントするメソッドをオーバーライドすると、スタックオーバーフローが発生します。
これは、ブロックのプロパティの1つからブロック自体への循環参照があるためです。つまり、一部のiには次のことが当てはまります。block.Statements[i]==ブロック

なぜそのような循環参照が存在するのですか？それを回避する方法は？ありがとう！

4

1 に答える 1

0

さらに調査した結果、実際には2つの主な問題があることがわかりました。

  1. VisitXXXメソッドは、ソースコードの抽象構文ツリーのノードにアクセスしていません が、実際には生成されたILのノードにアクセスしています。メソッドごとに生成されたIL命令と、メソッドごとに生成されたステートメントを比較するだけです。
    FxCopが真のASTビジターを提供できたら何ができたのだろうか。
  2. SourceContext私の最初の質問に答えるために、開発者がネストされたコードブロックを書きすぎないようにするには、メソッドコードを自分でスキャンする必要があります。つまり、のプロパティ内の開始行と終了行を取り出して、method.Bodyすべてを追跡する必要があります。 {'と'}'が見つかりました。'{'のインクリメントカウンターと'}'のデクリメントカウンター。それはうまくいくはずですよね？
于 2011-02-12T07:55:36.243 に答える