views:

466

answers:

5

This is something I'm not much consistent about and always curious about what other people do.

How do you access internal properties (private or public)?

For example you've got this property :

Private _Name As String

Public Property Name() As String
    Get
        Return _Name
    End Get
    Set(ByVal value As String)
        _Name = value
    End Set
End Property

In the same class within another function which one do you prefer? and why?

_Name = "Johnny"

or

Name = "Johnny"

Ignore the fact that I used Name instead of Me.Name.

+1  A: 

I prefer:

Name = "Johny"

For me, reason is quite simple, if something bad happens with _Name, you can always put some output in getter/setter and find out what is causing the trouble.

Max
+10  A: 

Personally I prefer to use the property where possible. This means you still get the validation, and you can easily put breakpoints on the property access. This doesn't work where you're trying to make a change to two properties which validate against each other - for instance, a "min and max" pair, where each has a validation constraint such that min <= max at all times. You might have (C#):

public void SetMinMax(int min, int max)
{
    if (max > min)
    {
        throw new ArgumentOutOfRangeException("max";
    }
    // We're okay now - no need to validate, so go straight to fields
    this.min = min;
    this.max = max;
}

At some point in the future, I'd like to see C# gain the ability to declare the backing field within the property, such that it's private to just the property:

public string Name
{
    string name;

    get { return name; }
    set
    {
        if (value == null)
        {
            throw new ArgumentNullException("value");
        }    
        name = value;
    }
}

Outside the property, you wouldn't be able to get at name at all, only Name. We already have this for automatically implemented properties, but they can't contain any logic.

Jon Skeet
Vote here for the feature mentioned above: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93337
Joe
+2  A: 

I would say

Name = "Johnny"

The reason is that I might have some validation (or trigger, or lazy initialization, or...), or might later decide to insert some validation, when assigning Name and I want to be sure to trigger that code.

finnsson
A: 

This is quite interesting, I think most of the people doing what I do

Me.Name = "Johnny"

or

Name = "Johnny"

However most of the projects that I've seen using

_Name = "Jonny"

style. Which I though was a bad idea, and thanks to answers you confirmed it. Even most of the auto-code generated code by several tools uses direct access.

Is there any particular performance hit? Or is compiler optimises it when there is no extra code in set or get.

dr. evil
The JIT will inline trivial properties, when not running in a debugger.
Jon Skeet
Cheers Jon, (shame I can not vote for this answer :) )
dr. evil
I voted and accepted the original one though.
dr. evil
A: 

Use property (Name). I believe a property should be sole "owner" of underlying field (_name).

Advantages of encapsulating field under a property:

  • Readability: Only one region of code where _name is changed or processed before returned.
  • Easy to set break-point, debug etc.
  • DRY: No code repeated as far as validation and processing is concerned.
  • Change resilience: Changing validation and processing will not affect code using property.
isntn