views:

578

answers:

6

If you have a Property that gets and sets to an instance variable then normally you always use the Property from outside that class to access it.

My question is should you also always do so within the class? I've always used the Property if there is one, even within the class, but would like to hear some arguments for and against as to which is the most correct and why.

Or is it just a matter of coding standards being used on the project?

+6  A: 

It depends on whether you want to apply any logic implemented within the property setter, and so you really have to decide on a case by case basis.

When you go directly to the private field, you know that the field is being set to exactly what you say.

When you go through the Property, the value gets set according to the setter logic, so you get any business rules or validation you want over values assigned to that field.

Pretty hard to come up with a rule about when doing either is 'correct', about the only one I'd say I follow is that in constructor initialisation I'd pretty much never use the Property.

David Hall
Good point. Use the field if you want to bypass logic in the property.
Brannon
A: 

I think it's purely preference.

Though, I find myself using the properties a lot more in C# 3.0 with the auto-property support:

class Foo {
    public string Value { get; set; }

    public void Write() {
        Console.Write(Value);
    }
}
Brannon
Auto properties are an interesting wrinkle - I love them because the stabilise the interface, but couldn't guess about how they influence using properties internal to a class. Do they make it more or less likely that I will miss setter logic that could mess things up, or are that just the same?
David Hall
By definition auto properties have no setter logic so they are functionally equivilent to a member variable. The difference being that later on you can change the implementation and introduce setter logic if required.
Aydsman
Yes, I know, what I wonder is if auto properties (and always using them) mean that when setter logic is implemented, it is more likely to be overlooked and cause problems. Not a technical issue, just a question of "What might cause me to make a dumb mistake?"
David Hall
A: 

Generally depending on the project coding standards I use a "_" or "m" preceding the name for my private class attributes. (Like below)

private int mVariable;
private int _Variable;

With those in front of the variable I recognize right away that I'm dealing with an internal variable for the class. Then when it comes to debugging later myself or someone else can immediately recognize that the code is dealing with an internal private variable and make an adjustment. So it comes down to readability for me.

ShaneB
_ makes them non-CLS compliant I believe
TheCodeJunkie
@Selfinflicted CLS compliance only applies to publicly visible fields/methods/ect.. Even if CLS compliance did apply, internal field names are removed when you build in Release mode anyways, so there is no reason that would matter.
Eric Haskins
+8  A: 

One of the stronger argument for accessing local (class scope) variables through properties is that you add a level of abstraction in your class. If you change any logic concerning how that field is stored then the rest of your code will be left unaffected.

For example you might change that from a local variable to a property of a child object, to a database call, to a webservice call, to a static property on a class and so on. When making the change it gives you a single point of change, the property, and you do not have to update the rest of your class since they all use the property.

Also using the property enables you to apply business rules on the value of the property instead of having to enforce the same rule at each location where you'd directly access the field. Again, encapsulation

With the introduction of automatic properties there's even less reason to explicitly have a local variable, unless you need to apply business rules on the get/set

TheCodeJunkie
On that note, I'd really love to have language syntax to prevent direct access to the backing field, even when one cannot use automatic properties for some reason.
Alan
+1 with the advent of automatic properties
Peter Lillevold
A: 

Yes I think you should use properties internally in your classes whenever possible. Properties are more flexible and allows you to add logic for validating it's value at a central place.

You can also delay the initialization of the the field to whenever the property is used instead of being forced to do it in the constructor (or everywhere the field is used). Example:

class Test {
   private int _checksum = -1;
   private int Checksum {
      get {
         if (_checksum == -1)
            _checksum = calculateChecksum();
         return checksum;
      }
   }
}
Mikael Sundberg
+1  A: 

Always Use Properties, Here are some of the reasons

  1. Easy to Use. In visual Studio you can use "Prop Tab Tab". You will get the property snippet
  2. Properties are language elements that are accessed as though they are data members
  3. .Net framework classes uses it, the data binding code classes in the .NET Framework support properties,
  4. Properties have all the language features of methods. Properties can be virtual
Raj