2

Someone told me that you could replace the following code:

private string name;

public string Name
{
    get;
    set;
}

with the following and suffer no ill effects:

public string Name;

I realize that the property, set like in the first example does pretty much the same as it would if I removed it and set the original attribute to publicbut is it bad programming practice to go with the second way for attributes for which you need just the basic getter and setter?

Matthew Watson
  • 104,400
  • 10
  • 158
  • 276
Nikola Luburic
  • 133
  • 1
  • 3
  • 10
  • 1
    Your first example will create two unrelated members, `name` and `Name`. The `Name` is an auto-property; it will not use the `name` field you wrote, but an "invisible" field with some crazy name that you can't use directly. If you want to use your own variable, provide bodies of the accessors, as in `public string Name { get { return name; } set { name = value; } }`. – Jeppe Stig Nielsen Apr 16 '13 at 12:24

6 Answers6

5

The second way isn't a property, it's a field. The reason you should always use properties for public-facing values is that converting from a field to a property constitutes a breaking change. Using a property allows you to later change the behavior of the getter or setter without breaking any code that references yours.

Keep in mind, the code public string Foo { get; set; }

is actually equivalent to

private string foo;
public string Foo 
{ 
    get { return foo; }
    set { foo = value; }
}
Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
4

When you use Properties you have better control of what properties have.

private string name;

public string Name
{
    get;
    set;
}

is wrong it should be either

public string Name
{
    get;
    set;
}

or

private string name;

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

sometimes when you want variable to be set only inside class u can use

public string Name
{
    get;
    private set;
}

Properties combine aspects of both fields and methods. To the user of an object, a property appears to be a field, accessing the property requires exactly the same syntax. To the implementer of a class, a property is one or two code blocks, representing a get accessor and/or a set accessor. The code block for the get accessor is executed when the property is read; the code block for the set accessor is executed when the property is assigned a new value. A property without a set accessor is considered read-only. A property without a get accessor is considered write-only. A property with both accessors is read-write.

Source: http://msdn.microsoft.com/en-us/library/w86s7x04(v=vs.80).aspx

Robert
  • 19,800
  • 5
  • 55
  • 85
0

I think the shortest way is to use Auto-Implemented Properties and some referenced information about them

In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. They also enable client code to create objects. When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors.

public string Name{ get; set;}

Patrick D'Souza
  • 3,491
  • 2
  • 22
  • 39
0

The shortest way of writing a property is using automatic getters and setters.

This is not quite what you've put in your question though, you've replaced a traditional property that has a backing field, with a field.

An automatic getter/setter looks like this:

public string Blah { get; set; }

This feature was introduced in C# 3, I believe. So you have to target this, or above, in order to use these.

SpaceBison
  • 3,704
  • 1
  • 30
  • 44
0
public string Name { get; set; }

msdn :

A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.

MHeads
  • 267
  • 1
  • 7
  • 18
0

A public property isn't the same as a public instance variable.

And this difference can matter. For instance, if you're using databound asp.net controls like DataTextField from DroDownListBox, it will fail if you set it to a instance variable instead of a public property.

Serge
  • 6,554
  • 5
  • 30
  • 56