Pain in the m_*!@#$

Everytime I do work for a client that has internal coding standards I find myself having to change between using the letter "m" or an underscore "_" or, God forbid, both of them "m_", when I need to name some variable that has a public property associated with it.

Here is what I consider to be a better fourth option. Enclose all of your backing variables into a structure. Then create a single instance of that structure and store it in a private variable called "Local".

It's easy to do, easy to read/write and provides a single method that works for everyone.


Public Class Employee
  
    Private Structure backingStore
        Public firstName As String
        Public lastName As String
    End Structure

    Private Local As New backingStore

    Public Property FirstName() As String
        Get
            Return Local.firstName
        End Get
        Set(ByVal value As String)
            Local.firstName = value
        End Set
    End Property

    End Class

1 comments:

April 8, 2010 at 9:33 AM Anonymous said...

Correct me if I'm wrong but, I'm not sure how well using a structure would scale in all cases with properties considering you would be using value types instead of reference types. I'm not 100% sure in all cases that it would be a good idea to go structure especially if there are a large number of instances of the object getting constructed.