Fields and properties Best Practice in C#

Question

Dear all, which one is the best practice using C# and why?
1.

private string name;

public string Name
{
  get { return name; }
  set { name = value; }
}

2.

public string Name { get; set; }

3.

protected string name;
public string Name
{
  get { return name; }
  set { name = value; }
}

4. Please add ...

Answer 1

Snippets 1 and 2 are both fine. The second is simply a more convenient way of writing the first for when you don't need access to the underlying field.

Snippet 3, however, should generally be avoided (unless you have some specific reason for needing it), as fields should almost always be private. If you need to provide a different way of setting the field for descendant classes (which is unlikely), then you could use methods or another property.

Remember that a protected member is essentially just a slightly more restricted public member, since it can be accessed by client code as long as it's in a descendant class. This means that client code can become tied directly into the implementation of the class rather than its interface, which is a bad thing!

Answer 2

The standard format typically:

private string name;

public string Name
{
    get { return name;}
    set { name= value; }
}

Fields will be private as a standard practice. Your properties will have the public protection modifier.

Answer 3

Start with the second snippet, i.e.

public string Name { get; set; }

Change it to the form of the first snippet when you need to add validation, or do some logic when the value is set.

I'd avoid the last option, as it would allow an overriding class to directly access the backing field which ties you to a specific implementation (it also means that your lovely validation can be bypassed)

Answer 4

Exposing a public property, is to avoid the exposing the public fields of the class to consumers. And properties allows you to control the way consumers use it (by get & set).

1st one is fine, In your 2nd sample(using public & protected) you just break that...

Answer 5

public string Name {get;set}

Second example is an automatic property and is generally used when you don't have any logic in getters and setters. It is also the short form of writing the first example.

Third example has a protected backing field, so the backing field can be accessed directly by a subclass.

Choose the format depending on what your goal is. Also, consider asking other team members if there is an agreed format already in place.

Answer 6

For the most part in applications I've written, if the getter and setter aren't more complicated than your examples, you probably want to minimize the code as much as possible for readability, so the shorthand approach is very useful. On the other hand, if you implement more complicated logic in the getters and setters (for example validation or parsing of some sort), you want to make sure that no user class bypasses your logic.

Also, and as Binary Worner noted in a comment, it depends on what you need, and what you want. You know the difference between private, protected and public, and thus you also know what you can and cannot do with your class depending on which one you choose. Which one is "the best" entirely depends on which behaviour you want (and don't want) to allow from other classes using this one.

Answer 7

Write automatic properties (Nº 2) as the default, unless your getter/setter has some kind of logic in it, otherwise the property (or the field) is there for nothing - you have to agree that a public property that direct accesses its private field is the same as a public field (or auto-propeprty).

Answer 8

#region LinkURL

    private string _LinkURL = String.Empty;
    public string LinkURL
    {
        get { return _LinkURL; }
        set { _LinkURL = value; }
    }

    #endregion LinkURL

This way is easy for code generation. For example if you have Excel with properties or a db table you would have to implement to a class you could check this regex tip:

Answer 9

Dear All, Thx for your responses