Suppress individual StyleCop messages

Question

I am looking for a way to suppress individual violation messages at the method or class level created by StyleCop.

To provide a simple example of what I'm looking for..

// 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 = "";
}

With the above, I'm wondering if there's a way to suppress the first violation, but still have the second reported.

I have searched and found a few related questions, but I'd like to know for certain if this is possible to do or not.

Thanks.

Answer 1

Before StyleCop logs a rule violation, it performs a check to see if the violation should be suppressed. It does this by checking whether a suppression is specified on the element (that is causing the violation) or any of its parents (e.g., a class would be a parent of a method, a method would be the parent of a variable declaration element in method). That means that two distinct violations inside a method would be suppressed by the suppression on the method itself.

The key here is how it searches for the matching element and what elements are searched. The following method is in CsParser.cs, within the CSharperParser project of the source:

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;
    }

Backing up a bit to understand the context, the parameter CsElement element will be the parent element of a parsed token where a violation has been detected and possibleElements is a list of CsElements that are tied to a suppression rule. Every element that comes through this method will match an enum of "ElementType" used by stylecop. A few example element types are class, field, constructor and using directive where one of these element types will be tied to the violation in question.

In the example I listed in my question, this is effectively what happens;

• A rule analyzer (such as SpacingRules.cs) would encounter the violation on 'var Temp ="";' and report it's line number/location and current token parent element to stylecop's core.
• Stylecop would then run through MatchElementWithPossibleElementsTraversingParents beginning with the parent element of the statement, which is the method 'Testing1()'.
• Our possibleMatch here is the CsElement, method 'Testing1()', that was parsed and added to the suppression list earlier since a suppression attribute was placed above it.
• The elements match, so the first violation would be suppressed.
• Right after that, another violation of the same type would be found on the next statement. However it's parent type is what would be searched first, so 'Testing1()'.

Hence, both violations are suppressed by the same suppression attribute, so the answer to my question is ultimately no.

Answer 2

The rule SA1306 is for field names to begin with lower case letters. I would avoid trying to suppress this as field names beginning with upper case letters can be mistaken for properties on the object.

I wouldn't recommend this style of coding and would always stick to properties beginning with upper case letters and fields beginning with lower case letters. This will aid readability and intention within the code.