бесконечный цикл анализа кода с помощью FxCop Introspection

Question

Я пытаюсь написать собственное правило анализа кода FxCop, которое будет предупреждать разработчиков о методах, содержащих слишком глубоко вложенные блоки кода, и будет призывать их перефакторизовать беспорядок.

ex.Я пытаюсь избежать следующей ситуации:

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

Я получаю переполнение стека, когда переопределяю метод VisitBlock(Block block)
, который считает глубину блока, потому что, очевидно, существует циклическая ссылка изсвойств блока к самому блоку.т.е. для некоторых i верно следующее: block.Statements [i] == block

Почему существует такая циклическая ссылка?Как этого избежать?Спасибо!

Answer 1

после еще одного исследования я выяснил, что у меня действительно две ДВУХ основных проблемы

1. Методы VisitXXX не посещают узлы в абстрактном синтаксическом дереве исходного кода но фактически посещают узлы в сгенерированном IL.Просто сравните сгенерированные инструкции IL для метода и сгенерированные операторы для метода. Бодь.
   Интересно, чего бы мы достигли, если бы FxCop мог предоставить нам настоящего посетителя AST?
2. Чтобы ответить на мой первоначальный вопрос, чтобы разработчики не писали слишком много блоков вложенного кода, нам нужно просто отсканировать код метода самостоятельно, я имею в виду, вынуть начальную и конечную строки внутри SourceContextсвойство method.Body и отслеживайте все '{' и '}', которые мы найдем.Счетчик приращений для '{' и счетчик приращений для '}'.Это должно работать, верно?