tags:

views:

1258

answers:

5

I noticed some people declare a private variable and then a public variable with the get and set statements:

private string myvariable = string.Empty;
public string MyVariable
{
    get { return myvariable; }
    set { myvariable = value ?? string.Empty; }
}

and then some people just do the following:

public string MyVariable
{
    get { return value; }
    set { MyVariable = value; }
}

Being a bear of little intelligence (yes, I have kids... why do you ask?) I can't figure out why you would choose one over the other. Isn't it just as effective in using a public variable that you can set any time using the set method of the variable?

Can anyone shed some light on this for me?

UPDATE: I corrected the second example after several people pointed out it wouldn't compile. Sorry about that, but the question still remains...

+18  A: 

Your second example won't compile, as the getter's value variable doesn't exist. Also, the setter would result in the eponymous StackOverflow exception!

In C# 3.0, you can use the following syntax to have the compiler create the private backing variable:

public string MyVariable { get; set; }

This wouldn't give you the extra null checking your first example has, though. You'd probably have to stick with your first example's method if you need custom logic in the setter.

Jarrod Dixon
+1 for any answer correctly using the word eponymous :)
Jon Skeet
I thought he should get points for using StackOverflow in something other than the name of this site... ;-)
Dscoduc
Heh, I'll never forget the meaning of eponymous, as my fav band, REM, has an album by that name.
Jarrod Dixon
+6  A: 

As others have mentioned, your second example doesn't compile.

However, there are very good reasons for not using a public field. In fact, your example demonstrates one of them - for this property, even if you set it to null, you'll get back an empty string if you ask for it again. Whether that's appropriate or not for that property (it's slightly odd) depends on the exact use - but it's not the behaviour of a public field.

I've got a whole article about why properties are better than public fields which you may find useful.

Jon Skeet
Heh, after reading your post, I realized I didn't even answer his question! +1 for doing the real work.
Jarrod Dixon
It helped that I've just been having an email debate on whether or not it was helpful to call mutable structs and public fields "evil" in another answer without giving an explanation. (I didn't have time for full reasoning at the time. I still think the advice was worth giving anyway.)
Jon Skeet
Jon has a 'whole article' on pretty much anything you ask regarding C# ;-) - and if he doesn't, he writes one!
Steven A. Lowe
+1  A: 

This is a very interesting read on this topic. However, I am pretty sure I have read somewhere on MSDN that objects with public variables are lighter than having properties (cant find the link).

Perpetualcoder
You'd have to define "lighter" for us to judge whether that's accurate or not.
Jon Skeet
You mean they don't result in a method call? Hopefully a future version of the MS JIT can rectify this.
Jonathan C Dickinson
Interesting article but a little hard to follow for a noob developer like me...
Dscoduc
I think the article meant to say what the code compiles down to in IL from my understanding of the article which I cant find now :(
Perpetualcoder
Not that the IL directly correlates to the JITted machine code. Trivial properties will almost always be inlined by the JITter.
Jon Skeet
A: 

Having a trivial getter and setter is very similar to using a public field.

The main argument for preferring getters and setters over properties used to be the uniform access principle, but since C# has properties is easy to replace a public field with a property and recompile.

It's not perfect (see Jon Skeet's article), but the arguments against using public fields aren't so strong that it makes it "evil", as long as you're aware of the difference.

Personally, I like being able to easily specify a default value for a public field.

orip
Aren't "gettters and setters" and "properties" equivalent in C#? And a public field of type T and a property of type T are not the same thing as far as I know: a change like that would change the interface of the class, wouldn't it?
peSHIr
It's a bad enough practice - when not *thoroughly* justified on a case-by-case basis (rather than just "it's quicker") that I stand by the word "evil".
Jon Skeet
(Although obviously that's hyperbole to some extent - it's a quick way of getting across the point that I think it's a really, really bad idea. I don't think it's morally sinful or anything like that, beyond the general sin of being inconsiderate towards those who have to maintain your code.)
Jon Skeet
@Jon: I'm not arguing against preferring properties, but in internal code (not part of a library interface) I'm not very put off by public members. Plus it's an honor to be downvoted by you :)
orip
A: 

My personal experience teaches me that example one is more flexible.

If you have an object with only public properties you'll allways have to use the getter/setter to access this property even within the object. If however you have the private variable then you can manipulate the private variable within your object you can do whatever you want.

You see sometimes you add extra logic in the getter or setter and if you allways have to use these you'll have take this extra logic in mind. But that is my personal experience.

S.

Sem Dendoncker