should we declare a local variable whenever we access a property?

say i have an auto property Public Property P As Integer and everytime I want to read开发者_运维问答 this variable P in a function, i will declare a local variable as such: dim _p = P then read _p instead of P.

I'm wondering does it make sense at all? will it actually make things slower (which of course isn't my intention)

Btw if we change the question to Public Property P As Object is there any change in the answer?

If you access Me.P (or _p) several hundred thousand times in the method, copying the property to a local variable will speed things up. However, for most cases, this isn't a concern, so you can do whichever, and it won't make a noticeable difference.

I'm generally in favor of making code easier to understand, so I'd favor accessing the property, unless you find that you need the additional performance. Me.P is easier to understand than _p is.

As far as coding style goes, I would greatly prefer that you didn't assign P to _p. When tracing the code to see where P is used I would miss its _p version. I don't think the speed difference is anything considerable.

It depends on whether your getter is doing anything other than returning a value that's already been calculated. If your getter is really just acting as a public variable then there is a negligible performance decrease. On the other hand, if your getter is doing any calculation it will be slower as each time you call the property, it has to run over the code in it.

All you seem to be doing is obfuscating your code. Just use the property directly. There are no implications beyond making your code easier to follow.

It makes sense because of the nature of properties. Properties allow the user to go back alter and specify code to format the returned value of a given property. You do not want to run that code every time you reference it in the same method.

Here is C# code. I am sure you will understand what it does even if unfamiliar with C#:

public int MyNumber
{
    get
    {
        return GetValueFromDatabase();
    }
}

public void main()
{
    lblFirst.Text = MyNumber;
    lblSecond.Text = MyNumber;
    lblThird.Text = MyNumber;
}

In this example, the database has been called three times, as opposed to the following in which it is called only once:

public void main()
{
    int _myNumber = MyNumber;
    lblFirst.Text = _myNumber;
    lblSecond.Text = _myNumber;
    lblThird.Text = _myNumber;
}

Keep in mind that just because your property does not do any sort of fancy calculation at the moment does not mean that it won't in the future. You do not want to code such that you will have to go back later and modify several different places just because of a one line change of code.

I only do this as a means of removing code duplication. If the property is used more than once, then I use the "Introduce Variable" refactoring to replace the property with a local that contains the same value.

Otherwise, I see no reason to do this, and many reasons to not do it.

The automatic implemented properties have the same performance as the classic proerties as the compiler will generate the same as the way what it generates for normal class that doens’t have auto-implemented properties.

No need to worry about performance. Get benefit of the short format whenever you dont need to implement more logic inside the property.