Fields vs Properties for private class variables

Question

For private class variables, which one is preferred?

If you have a property like int limit, you want it to be:

int Limit {get; set;}

and use it inside the class, like so:

this.Limit

Is there a reason to use it or not use it? Maybe for performance reasons?

I wonder if this is a good practice.

Solution 1

For a private member, I only make it a property when getting and/or setting the value should cause something else to occur, like:

private int Limit
{
   get
   {
       EnsureValue();
       return this._limit;
   }
}

Otherwise, fields are fine. If you need to increase their accessibility, it's already a big enough change that making it a property at that point isn't a huge deal.

Edit: as Scott reminds us in the comments, side effects in properties can often cause more pain than anything else. Don't violate Single Responsibility and limit property logic to consistent, logical operations on the value only that must be done at the gate - such as lazy loading (as in the example above), transforming an internal structure into a publicly-useful format, etc.

Solution 2

The only real benefit an auto-property has over a field when the accessibility is private is that you can set a breakpoint on accesses and updates of the variable. If that is important to your scenario then definitely use an auto-property. Otherwise, given there is no substantial advantage, I choose to go with the simplest construct which is a field.

Solution 3

I would say its good practice to use a property. If ever you had to expose the limit value and used a local member it will require more coding while if its a property it would only require a change of its modifier.

I think it's cleaner also.

Solution 4

From my perspective, using properties in lieu of variables boils down to:

Pros

• Can set a break point for debugging, as Jared mentioned,
• Can cause side-effects, like Rex's EnsureValue(),
• The get and set can have different access restrictions (public get, protected set),
• Can be utilized in Property Editors,

Cons

• Slower access, uses method calls.
• Code bulk, harder to read (IMO).
• More difficult to initialize, like requiring EnsureValue();

Not all of these apply to int Limit {get; set;} style properties.

Solution 5

Granted, since it's a private API, its an implementation detail - you can do whatever you want here. However, there is very little reason to not use a property, even for private classes. The properties get inlined away by the JIT, unless there is extra code in place, so there isn't really a performance impact.

The biggest reasons to prefer properties, IMO, are:

1. Consistency in your API - You'll want properties in publicly exposed APIs, so making them in the private API will make your programming exprience more consistent, which leads to less bugs due to better maintainability
2. Easier to convert private class to public

View more solutions