How to prevent showing backing private fields of class properties in the Locals window?

Question

Although an experienced VBA programmer it is the first time that I make my own classes (objects). I am surprised to see that all properties are 'duplicated' in the Locals Window. A small example (break at 'End Sub'):

' Class module:
Private pName As String

Public Property Let Name(inValue As String)
    pName = inValue
End Property
Public Property Get Name() As String
    Name = pName
End Property

' Normal module:
Sub Test()
    Dim objTest As cTest
    Set objTest = New cTest
    objTest.Name = "John Doe"
End Sub

Why are both Name and pName shown in the Locals Window? Can I in some way get rid of pName?

Answer 1

As comments & answers already said, that's just the VBE being helpful.

However if you find it noisy to have the private fields and public members listed in the locals toolwindow, there's a way to nicely clean it up - here I put the Test procedure inside ThisWorkbook, and left the class named Class1:

So what's going on here? What's this?

Here's Class1:

Option Explicit

Private Type TClass1
    Name As String
    '...other members...
End Type

Private this As TClass1

Public Property Get Name() As String
    Name = this.Name
End Property

Public Property Let Name(ByVal value As String)
    this.Name = value
End Property

The class only has 1 private field, a user-defined type value named this, which holds all the encapsulated data members.

As a result, the properties' underlying fields are effectively hidden, or rather, they're all regrouped under this, so you won't see the underlying field values unless you want to see them:

And as an additional benefit, you don't need any pseudo-Hungarian prefixes anymore, the properties' implementations are crystal-clear, and best of all the properties have the exact same identifier name as their backing field.

Answer 2

All the Inspection windows not only show the public interface of the objects to you, but also their private members. AFAIK there is nothing you can do about it.

Consider it a nice feature to get even more insights while debugging.

In my experience this is less of an issue in real world objects as they tend to have more fields and properties. Assuming a consistent naming (as your example shows), fields and properties are nicely grouped together.