In a class module, why use an unrestricted property?

Over the years, I have followed the “best practice” of always using a property get and let/set combination rather than just declaring a public variable. But, over the last few months I’ve started questioning this dictum.

Now, before people start jumping up and down, I am aware of the many very, very good reasons why one should use properties rather than public variables. This comment is *limited* to the case where the property provides unrestricted access to the underlying value.

For those who want a clarification of what I am writing about, in a class module, one could have either

Option Explicit

Public R As Single


Option Explicit

Dim xR As Single
Public Property Get R() As Single
    R = xR
    End Property
Public Property Let R(uR As Single)
    xR = uR
    End Property

As far as a consumer of this class goes, the code would be identical irrespective of which of the above methods the developer of the class used.

One could argue that at some point, the developer may want to enforce a check on R (e.g., enforce that R > 0). Or one might want to provide a property that is read-only or write-once-read-many or one of many other scenarios where a property Get / Let would be required. But, until that happens, what’s the difference whether the class developer uses an unrestricted property or a public variable?

Posted in Uncategorized

11 thoughts on “In a class module, why use an unrestricted property?

  1. Tushar,

    I agree. I typically use the public variable approach whenever I can get away with it, and only use Property Let/Set/Get when I need one of the exception cases you mention, like a required validation, write once read many, etc.

    I mean, really, for a simple numeric or text value, what do you gain using Property beside more lines of code?


  2. The only reason I can see is when this property is widely used through your workbook and then you want to add a property check with Set.
    You’ll have to rewrite all the code that refers to that property and it can be long.

  3. Better to develop the habit of doing it upfront (and risk only the possibility of it being unnecessary) than having to refactor later.

  4. Well, if we’re talking strictly classes here, then the biggest benefit of using properties, unstricted or not, is that they pop up in the IntelliSense, whereas a straight variable does not. And I like IntelliSense. Makes me coding life easier, and presumably, whoever is maintaining the code after I’m done with it.

  5. Scott,

    Public variables for a class show up in IntelliSense.

    If they didn’t, then yes, it would always be worth it to set up Properties the “right” way. But they do show up :)


  6. Patrick-
    I had NO idea they did that. I’ve never even tried it.

    Probably because I use properties and private variables, and never used a public one. ;-)

    Learn something new everyday.

    (Which still won’t stop me from using properties ;-) )

  7. Its an easy refactor to add the get/set later, as it is only in the class.

    Personally though, I rarely use classes in Excel VBA as I rarely need to maintain and manage state (which VBA is rubbish at anyway).

    Mind you I dont often use public variables either.

  8. I guess that using a Property is necessary if more then one instance of the class may be created.
    If there’s a public variable in a class with two opened instances it will be hard to tell apart two variables with the same name :)
    Cheers, Daan

Posting code? Use <pre> tags for VBA and <code> tags for inline.

Leave a Reply

Your email address will not be published.