The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Using properties in C#

When writing a public property in C#, should I write it like this:

public int IntProperty { get; set; }


private int intProperty;
public int IntProperty {
  get {
    return intProperty;
  set {
    intProperty = value;

Assuming that the property can be read/written without any limitations or checking, which should I choose and why? The first one seems of course simpler and shorter to me.

If I choose the second one, should I use the private intProperty or the public property IntProperty inside the class?

Petr Veit Send private email
Thursday, December 13, 2007
Someone is bound to correct me, but I'm under the impression that the compiler output is identical in both cases.
Ron Porter Send private email
Thursday, December 13, 2007
You're correct Ron. This is a new feature in VS 2008 called automatic properties and in both cases the compiler produces the same code.

Of course if you're using VS 2005 then this has a different meaning - it's a declaration of a read / writable property that you'll have to implement in a derived class in which case ignore the following...

My rule of thumb would be to use the top version wherever possible but if you actually need a setter or getter to do something other than set or return an internally held value, then revert to creating a private variable and thus your second option.
John Conners Send private email
Thursday, December 13, 2007
"IntProperty" ??
Larry Lard
Thursday, December 13, 2007
There may be a difference between the way the two are serialized to binary. That difference doesn't matter to a lot of people but if you are using WCF then the output will be different because in the first case you are not in control of the name generated by the compiler for the private member variable backing the property. So basically any time you need to control this (reflection, serialization, etc.) you will want to go with the second option.
Thursday, December 13, 2007
It's also probably worth mentioning that using the first option means that your code won't compile in VS2005. As someone earlier pointed out, this is a feature of VS2008 only. If you will potentially be sharing code with someone else you might want to consider this. I can't tell you how many times I've had little libraries of code that I've ended up using across projects that may not have been using the same version of visual studio or even the .NET framework.
Thursday, December 13, 2007
Say, I want to put a breakpoint and see who and when reading/setting (separately) my property - how exactly I do that in such a case (#1)?
asmguru62 Send private email
Thursday, December 13, 2007
>> If I choose the second one, should I use the private intProperty or the public property IntProperty inside the class? <<

That depends on whether the setter does anything besides just store the value (aka has a side-effect).

If my property definition is:

public int MyIntProperty
  get { return _myIntProperty; }
      CheckForValidity(value);  // throws
      _myIntProperty = value;

Then using MyIntProperty in my class's methods will result in the value being checked to see if it's valid (and possibly throwing an exception).  Using the private member _myIntProperty will skip that check. 

It's up to you to decide if that's safe.
Thursday, December 13, 2007
Automatic properties are just a shortcut. In cases where all a property does is get and/or set a field, they're fine. But you cannot manipulate the storage that is allocated to the property because you don't know its name at compile-time, so you have to go through the property itself, even inside the class.

This is fine in principle, but if you then want to put some logic into the getter or setter, you have to break it out and put in a field declaration and you may also have to change code in your class which accesses the property value if you want to *avoid* the logic internally.

The main advantage is not having to create fields for dozens of simple properties with the beneficial side-effect that if you do decide to add logic later it doesn't change the signature of your type - which it would do had you used, say, a public field originally.
.NET Guy Send private email
Friday, December 14, 2007
I'd say use #2 because it's more common.  I haven't tried VS2008 yet (I'm just now planning to move my company to .NET 2.0!  Maybe I should wait and do 3.5), but because I've used 2005 the first one looks like what you'd define for an interface, not an implementation.

They might compile to the same thing, but IMO the second one is clearer at explaining what it does.
Newbie IT Director
Friday, December 14, 2007
Thank you for all the replies!

After reading all of them, why not to declare it just as a public field:

public int IntProperty;

Are there any downsides?
Petr Veit
Friday, December 14, 2007
Well declaring it as a public field has it's own set of pro's and con's which have been debated at length both here and on the Internet. Let's not get into that again if possible.

Use your Google-Fu and search for "properties vs. public fields" and you'll find arguments for both sides.
Friday, December 14, 2007
If your sitations is one of the sitations in which it doesn't matter which you use, because if you get bored of one way you can just change it to the other and recompile everything, you're safe: it then doesn't matter which you use, because if you get bored of doing it one way you can just change it to the other and recompile everything.
Saturday, December 15, 2007
I think its better to use #2 in all cases, otherwise why not use a field? Much simpler. Makes no sense to me why I would ever use #1 or need it, other than wanting to avoiding typing another typed field for every property, which is optional anyway in VS2005 properties.

By using the full property with set and get you can use your field to copntrol inital default values, can add logic that extends the property, is more mangeable for large development teams, and more secure, where in cases you have a public property but need to keep the value private in the class for some other reason.
 As far as public versus private, I would use protected on the properties, and private on fields used by them, then public on those values you need to access in your pages other projects and classes.

Saturday, December 15, 2007
Re public fields - these are almost always a bad idea. I do use them in structs and pure-data types, but never in classes.

The rationale is simple - you might think that this is a simple value that your class client needs to get (and maybe set) and so you think - public field! But then later on you realise that to do the whizzy new feature you want to add to the class you need to be able to have something happen before the client can read that value; or when they set it. And so now you need logic around the getting or setting of that value. Which means you have to turn it into a property. This breaks not only your metadata interface (requiring a recompile of anything dependent on it) but also any classes that inherit from it and depend on that behaviour.

All in all, you can end up re-writing lots of code and re-compiling lots of code just to cope with a tiny change which could have been avoided if you had only made it a property in the first place.

This is what properties are for, and it's the main reason why there's an almost superstitious prohibition on using public fields in .NET.

My advice - don't do it. You'll regret it.
.NET Guy Send private email
Sunday, December 16, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz