Подавлять отдельные сообщения StyleCop

Question

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

Чтобы обеспечить простой пример того, что я ищу ..

// Attribute will suppress all occurrences of violation "SA1306" 
// within the Testing1() method. 
[SuppressMessage("StyleCop.CSharp.NamingRules", 
       "SA1306:FieldNamesMustBeginWithLowerCaseLetter", 
        Justification = "Reviewed. Suppression is OK here.")] 
public void Testing1() 
{ 
    //Fires off SA1306 
    var Temp = ""; 
    //Also fires off SA1306 
    var Temp2 = ""; 
} 

С выше, я задаюсь вопросом, есть ли способ подавить первое нарушение, но все еще есть второй сообщили.

Я искал и нашел несколько связанных вопросов, но я хотел бы знать наверняка, можно ли это делать или нет.

Спасибо.

Answer 1

Перед тем, как StyleCop регистрирует нарушение правила, он выполняет проверку, чтобы убедиться, что нарушение должно быть подавлено. Он делает это, проверяя, указано ли подавление в элементе (который вызывает нарушение) или любой из его родителей (например, класс будет родителем метода, метод будет родителем элемента объявления переменной в метод). Это означает, что два различных нарушения внутри метода будут подавлены подавлением самого метода.

Ключевым моментом является поиск соответствующего элемента и поиск элементов. Следующий метод в CsParser.cs, в рамках проекта CSharperParser источника:

private static bool MatchElementWithPossibleElementsTraversingParents(CsElement element, IList<CsElement> possibleElements) 
    { 
     Param.AssertNotNull(element, "element"); 
     Param.AssertNotNull(possibleElements, "possibleElements"); 

     // Loop through each possible element using a for-style loop rather than a foreach, since this 
     // is faster and this method is called very often. 
     for (int i = 0; i < possibleElements.Count; ++i) 
     { 
      CsElement possibleMatch = possibleElements[i]; 

      // Walk through the element and each of its parents to see if any is a match. 
      CsElement item = element; 
      while (item != null) 
      { 

       if (item == possibleMatch) 
       { 
        return true; 
       } 

       item = item.FindParentElement(); 
      } 
     } 

     return false; 
    } 

Резервное копирование немного, чтобы понять контекст, элемент параметра CsElement будет родительский элемент анализируемой лексемы, где нарушение имеет были обнаружены и возможныеElements - список CsElements, привязанных к правилу подавления. Каждый элемент, который проходит через этот метод, будет соответствовать перечислению «ElementType», используемому стилем. Несколько типов элементов элемента - это класс, поле, конструктор и использование директивы, в которой один из этих типов элементов будет привязан к рассматриваемому нарушению.

В примере, указанном в моем вопросе, это фактически то, что происходит;

• Анализатор правил (например, SpacingRules.cs) столкнулся с нарушением на 'var Temp = ""; и сообщите, что это номер строки/местоположения строки и текущий родительский элемент токена в ядре stylecop.
• Stylecop затем будет запускаться через MatchElementWithPossibleElementsTraversingParents, начиная с родительского элемента инструкции, который является методом 'Testing1()'.
• Наш методMatch здесь - это метод CsElement, метод 'Testing1()', который был разобран и добавлен в список подавления ранее, так как над ним был помещен атрибут подавления.
• Элементы соответствуют, поэтому первое нарушение будет подавлено.
• Сразу после этого в следующем утверждении будет найдено другое нарушение того же типа. Однако это родительский тип - это то, что будет искать сначала, так что «Testing1()».

Следовательно, оба нарушения подавляются одним и тем же атрибутом подавления, поэтому ответ на мой вопрос в конечном итоге отсутствует.

Answer 2

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

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