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

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

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

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

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


person Paul    schedule 09.02.2011    source источник
comment
Предоставьте пример кода (как для правила, так и для цели), который воспроизводит проблему.   -  person Nicole Calinoiu    schedule 10.02.2011


Ответы (1)


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

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