4

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

tanascius
  • 53,078
  • 22
  • 114
  • 136
yayan
  • 79
  • 1
  • 5
  • 4
    Use which ever you need, one isn't better than the other. They each are eligable depending on what you're trying to achieve. – Binary Worrier Feb 15 '10 at 12:01
  • 1
    Duplicate - http://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c – ChrisF Feb 16 '10 at 08:40
  • @yayan: If you find one of the answers useful, could you mark it as accepted using the tick icon beneath the votes please? – Will Vousden Apr 18 '10 at 08:49

9 Answers9

14

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!

Will Vousden
  • 32,488
  • 9
  • 84
  • 95
  • 2
    + for the protected warning. Inheritors should be forced to use the properties of the base class. –  Feb 15 '10 at 12:18
11

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)

Rowland Shaw
  • 37,700
  • 14
  • 97
  • 166
0

How is the best practice in getting a read from two properties by the field or by the get operation? my own conclusion is to get from the field since that is the information you wanna handle, just need to ask if iam thinking wrong.

   private string _key;
   private string _subKey;
   private string _fullKey;

   public string SubKey
    {
        get
        {
            return _key;
        }
        set
        {
            _key = value;
        }
    }

    public string SubKey
    {
        get
        {
            return _subKey;
        }
        set
        {
            _subKey = value;
        }
    }

1.

public string FullKey
{
get
{
return _subKey + _key;
}
}  

2.

public string FullKey{
get
{
return SubKey + Key
}
}
Martea
  • 507
  • 1
  • 5
  • 18
0

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.

IAbstract
  • 19,551
  • 15
  • 98
  • 146
0

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

RameshVel
  • 64,778
  • 30
  • 169
  • 213
0
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.

Arnold Zokas
  • 8,306
  • 6
  • 50
  • 76
0

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.

Tomas Aschan
  • 58,548
  • 56
  • 243
  • 402
0

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).

Pedro
  • 11,514
  • 5
  • 27
  • 40
0
    #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:

Yordan Georgiev
  • 5,114
  • 1
  • 56
  • 53