CA1500 vs. SA1309 - Which one wins?

问题

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'd like to see what the general consensus is with regard to these two rules.

Rule CA1500 says don't make parameter names and private field names the same.

Rule SA1309, on the other hand, says don't prefix members with underscore or "m_".

This leaves us with little options for distinguishing private backing fields from their corresponding parameters. Take these examples.

SA1309 complains:

class SomeClass
{
    int _someField;

    public SomeClass(int someField)
    {
        this._someField = someField;
    }
}

CA1500 complains:

class SomeClass
{
    int someField;

    public SomeClass(int someField)
    {
        this.someField = someField;
    }
}

What options do I have? I don't want to make the private backing field PascalCase, because this is the (I believe fairly universal) convention for public fields/properties. And I don't want to rename one or the other, just for the sake of resolving ambiguity.

So I'm left with one of the above two, which would require me to suppress one of the SA/CA rules.

What do you guys typically do? And more importantly, what do the authors of these rules think you should do (as neither provide alternative solutions in their documentation)?

回答1:

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.

回答2:

Here is my usual solution:

class SomeClass
{
    int SomeField{get;set;}

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

回答3:

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.

回答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.

回答5:

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

回答6:

There's no conflict. Change the parameter name.

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

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

来源：https://stackoverflow.com/questions/3215395/ca1500-vs-sa1309-which-one-wins

标签

naming-conventions

code-analysis

fxcop

stylecop