CA1500 vs. SA1309 - Which one wins?

Question

I\'ll prefix by saying that I understand that both Code Analysis and StyleCop are meant as guidelines, and many people chose to ignore these anyway. But having said that, I

Answer 1

Here is my usual solution:

class SomeClass
{
    int SomeField{get;set;}

    public SomeClass(int someField)
    {
        SomeField = someField;
    }
}

Answer 2

There's no conflict. Change the parameter name.

public class SomeClass
{
    private int namedField { get; set; }

    public SomeClass(int differentlyNamedField)
    {
        this.namedField = differentlyNamedField;
    }
}

Answer 3

The only alternative I can think of that seems like it would satisfy both rules and that I have actually seen used anywhere is something like the following. I don't follow this convention myself, as it seems clumsy.

public class Class1
{
    // prefix private fields with "m"
    private int mValue1;

    public int Value1
    {
        get { return mValue1; }
        set { mValue1 = value; }
    }

    private string mValue2;

    public string Value2
    {
        get { return mValue2; }
        set { mValue2 = value; }
    }

    // prefix parameters with "p"
    public bool PerformAction(int pValue1, string pValue2)
    {
        if (pValue1 > mValue1)
        {
            mValue2 = pValue2;
            return true;
        }
        else
        {
            return (mValue2 == pValue2);
        }
    }
}

Answer 4

Simple, use the suffix 'Field' for private fields when there's a class:

 private Int32 counterField;

 public Int32 Counter
 {
     get
     {
          return this.counterField;
     }

     set
     {
           if (this.counterField != value)
           {
                this.counterField = value;
                this.OnPropertyChanged("Counter");
            }
      }

And you can satisfy both rules. Decorating your variables with any characters or hungarian prefixes is tribal. Everybody can find a rule that they don't like in StyleCop or FXCop, but a standard only works when everyone uses it. The benefits of an automated scrubber of code far outweigh your own personal 'artistic' contributions to the language.

Answer 5

We turn off SA1309. The reasoning behind it is fairly weak.

Our team feels that the well-accepted practice of private members starting with underscores far outweighs the idea that someone might use a different editor on the code, which never happens in our shop anyway. As to providing an "immediate differentiation", the underscore does that as well.

If you really have developers that still use "m_" though and you still need to check for that, you could write a quick rule for just that.

Answer 6

Based on what I've seen from Microsoft themselves, I say CA1500 wins.

If you look at the BCL, most of the code prefixes local fields with an underscore.