What is the difference…? [C# properties GET/SET ways]

Question

I know in C# you can easily create accessors to a data type, for example, by doing the following:

public class DCCProbeData
{
    public float _linearActual { get; set; }
    public float _rotaryActual { get; set; }
}

However my colleague, advised me to do it this way:

public class DCCProbeData
{
    private float _linearActual = 0f;

    public float LinearActual
    {
        get { return _linearActual; }
        set { _linearActual = value; }
    }
    private float _rotaryActual = 0f;

    public float RotaryActual
    {
        get { return _rotaryActual; }
        set { _rotaryActual = value; }
    } 
}

My way seems simpler, and more concise. What are the differences and benefits of doing it either way?

Thanks

Edit Just a note, my colleague was able to generate the code for the "second way" using the Refactor option within the Class Details pane most easily found in a Diagram file. This makes it easy to add many Properties without having to manually create the accessors.

Answer 1

"Your way" just tells the compiler to create the second option. Unless you do something else in the getter or setter, they are functionally identical.

However, with "your way", I would recommend using the proper C# naming conventions. I would personally write this as:

public class DccProbeData
{
    public float LinearActual { get; set; }
    public float RotaryActual { get; set; }
}

Answer 2

The only difference is that you've named the fields.

(I'd stick with your colleagues naming convention for public properties though.)

Answer 3

They do the same thing internally. The only difference is that you cannot directly access the backing field variable using Auto Implemented Properties.

Answer 4

They are technically the same... the get/set is shorthand ( auto property ).

Lots of questions on SO about this:

1. When to use get; set; in c#
2. What is the { get; set; } syntax in C#?
3. Auto-Implemented Properties c#

Answer 5

您的方式不允许您初始化值，并且您的同事的方式遵循更标准的命名约定。

Answer 6

I would like to add something that I haven't seen in the other answers, which makes #2 a better choice:

Using the first method you cannot set a breakpoint on the get and set .

Using the second method you can set a breakpoint on the get and set , which is very helpful for debugging anything accessing your private variable.

Answer 7

Okay, the names have been mentioned before. It's also worth noting that as well as not being with the normal .NET conventions, beginning a public name with an underscore is not CLS-compliant (indeed, one reason for using it for private names is precisely because of this, it makes the distinction clearer, and should result in a warning with some code-checkers if you accidentally have the wrong access level).

Names aside, the one advantage to the latter form is that you can add more complicated code. Still, it's a non-breaking change to go from the former style to the latter, so there's no reason to do it before it's needed.

Answer 8

The first way is the way to go when you need simple properties with get and set and private storage done for you.

Use the second way if you need to do something special when you get or set the value.

Also, I recommend you stick to naming conventions using FxCop or ReSharper.

Answer 9

I believe at the IL level, they both end up the same. In the background, VS creates autonamed variables for you when using the auto getters and setters.

Answer 10

The only way this could possibly be better is if you feel you will be adding more logic to the getters and setters at a later date.

Even then, this seems a little pointless.

Answer 11

There is no difference , however prior to C# 3 you had to use the long way. At the end of the day it's a C# feature - syntactic sugar . They are both functionally identical.

Answer 12

They are the same in the sense that your code sample will automatically generate backing fields.

But the two code samples are different because the names of the properties are not the same ( LinearActual vs linearActual )

Answer 13

Things you can do when you don't use auto-implemented properties:

• initialize to a default value
• access or annotate the backing field (attributes)
• read-only backing fields or immutability
• set a breakpoint on access
• have custom code around access to the variable
• Use [System.ComponentModel.EditorBrowsableAttribute()] to enable custom logic on the accessors that you avoid accidently bypassing while coding
  • hides the backing field from intellisense

Conversion between the two ways is made very simple with ReSharper.

This is not to say don't use them by all means use them, unless you have a need for any of the other functionality listed.