Code comparison - Which is better or unnecessary?

Question

Possible Duplicate:
Difference between Property and Field in C#

public class Test
{
    public bool testData1;
    public string testData2;
}

or

public class Test
{
    public bool TestData1 { get; set; }
    public string TestData2 { get; set; }
}

or

public class Test
{
    private bool testData1;
    private string testData2;

    public bool TestData1 { get { return testData1; } set { testData1 = value; } }
    public string TestData2 { get { return testData2; } set { testData2 = value; } }
}

Which optimized code is better or unnecessary? And Why?

Isn't that last one holds a lot unnecessary data?

======= EDIT:

I think in that case:

public class Test
{
    public Test(bool testData1)
    {
         this.testData1 = testData1;
    }
    private bool testData1;

    public bool TestData1 { get { return testData1; } }
    public string TestData2 { get; set; }
}

having fields in background is required. Isn't it?

score 8 · Accepted Answer · answered Feb 05 '12 at 20:10

8

You should not have public fields, use properties instead so you can change the internal implementation later on if neccessary - so 2) wins. 3) is just how auto properties are implemented under the hood so is equivalent to 2)

answered Feb 05 '12 at 20:10

BrokenGlass

158,293
28
286
335

One more point: (2) is more concise – and, thereby, typically preferable – over (3). Exceptions exists, the main one being when you want to assign an initial value to the backing field, which you can’t do though (2). – Douglas Feb 05 '12 at 20:13
@Douglas Not just initial value, but some logic too ie put there a value under only certain conditions. – Tomas Voracek Feb 05 '12 at 20:15
Public fields can be used when they constants, such as [`Math.PI`](http://msdn.microsoft.com/en-us/library/system.math.pi.aspx). – Paolo Moretti Feb 05 '12 at 20:15
@PaoloMoretti: Absolutely - what that says though is you know already that this field *is never going to change* so in that case using a field makes sense, also it is a special case since that makes the field static as well. – BrokenGlass Feb 05 '12 at 20:18
Please check my edit (New question) – haxxoromer Feb 05 '12 at 20:22
@haxxoromer: No you don't need a field for this - you can set your auto property value in the constructor as well: `TestData1 = testData1;` also see http://stackoverflow.com/questions/169220/initializing-c-sharp-auto-properties – BrokenGlass Feb 05 '12 at 20:24

score 5 · Answer 2 · answered Feb 05 '12 at 20:11

5

The second two are equivalent. Just different syntax for saying the same thing.

The first is different- it exposes fields, as opposed to properties. The difference between fields and properties has been covered ad nauseum on the web.

answered Feb 05 '12 at 20:11

Chris Shain

50,833
6
93
125

score 2 · Answer 3 · answered Feb 05 '12 at 20:10

2

Second and third are same. First is bad, because if you change something (name, type) then you broke class interface.

answered Feb 05 '12 at 20:10

Tomas Voracek

5,886
1
25
41

Frederik Gheysels · Answer 4 · 2012-02-06T13:09:54.217

The first example is semantically different then the other two.

In the first example, you're using fields instead of properties.

The second example is equivalent to the third; the compiler will generate the backing fields itself. So, the second example is easier to read and imho cleaner.

regarding your editted question: Not necessarly. You can perfectly do this:

public class MyClass
{

    MyClass( bool x )
    {
       TestData1 = x;
    }

    public bool TestData1
    {
       get;
       private set;
    }
}

score 2 · Answer 5 · answered Feb 05 '12 at 20:14

2

Using number one in production code should be out of the question, because having public fields is a sure sign of poor use of encapsulation.

The numbers two and three are similar, with one important difference: if you plan to serialize your class, you should prefer #3, because you have tighter control over the variables that you can serialize. Other than that, #2 and #3 are identical. I always start with #2, and go for #3 only when necessary.

answered Feb 05 '12 at 20:14

Sergey Kalinichenko

714,442
84
1,110
1,523

that's generally good advice: start with an auto property and refactor to using a backing field later *if necessary*. – BrokenGlass Feb 05 '12 at 20:27

Code comparison - Which is better or unnecessary?

5 Answers5

Linked