Question

One of the things that always stumbles me when working with WPF is the naming convention.

So this is what I have for XAML:

<StatusBar Grid.Row="2" MinHeight="20" Name="StatusBar">
        <StatusBarItem>
            <Border BorderBrush="Black" BorderThickness=".25,.25,0,0">
                <Border BorderBrush="White" BorderThickness="0,0,.25,.25">
                    <TextBlock Name="StatusBarText" Margin="2,2,2,2" >Ready</TextBlock>
                </Border>
            </Border>
        </StatusBarItem>

        <StatusBarItem>
            <Border BorderBrush="Black" BorderThickness=".25,.25,0,0">
                <Border BorderBrush="White" BorderThickness="0,0,.25,.25">
                    <TextBlock Name="FilePathText" Margin="2,2,2,2" >File Path</TextBlock>
                </Border>
            </Border>
        </StatusBarItem>
    </StatusBar>

The content of TextBlock will be databound. I am really not sure what to name my UI elements and properties to avoid any potential ambiguity.

    public string StatusBarText 
   //Maybe StatusText instead of StatusBarText since this 
   //indicates the current status of the application (Ready,Running,Error etc)?
    {
        get { return statusBarText; }
        set
        {
            statusBarText = value;
            NotifyOfPropertyChange(() => StatusBarText);
        }
    }

    public string FilePathText
    {
        get { return filePathText; }
        set
        {
            filePathText = value;
            NotifyOfPropertyChange(() => filePathText);
        }
    }

I mean are those names for properties fine? I feel like if another person is to take a look at those property names, he/she has no way of figuring out that those strings are used for the StatusBar textblock. I guess Hungarian notation might solve this problem but not many people think that’s a good idea nowadays.

What are your suggestions?

Answer 1

If you’re using MVVM properly, controls generally do not need names because they are never referenced. (Only the data that they’re bound to.)

The only controls that need names are ones that you absolutely must name to reference in code-behind or something similar, or things that might have relative bindings pointing at them that cannot be relied on to be identified by type.

As far as naming convention goes, I’ve adopted the UI/ux naming convention for views/controls respectively. The naming clue just goes so far as to hint that it is a control, and not so specific as to the type of control. That way the type can be changed to reflect business needs or wants without requiring you to go and rename references or leave misleading references.