Is there a good pratice for naming form controls which are purely cosmetic?
If not, any suggestions for variable names for these controls?
E.g A label (which never changes) above a text box.
Is there a good pratice for naming form controls which are purely cosmetic?
If not, any suggestions for variable names for these controls?
E.g A label (which never changes) above a text box.
Many developers use logical names for their controls that will allow them to recognize their purpose even after a long time has passed. One thing you should most likely avoid is putting the control type in the name. If you need to change the control but still with the same purpose you can keep the name. For instance: in a login form a label could be userNamePrompt and the textbox userNameInput. Now suppose you decide to change the textbox to a combobox with a list of available names. The name userNameInput will still be appropriate and will most likely require less changes in your code.
I agree with tinstaafl that you should give meaningful names to all your controls. If you are using Visual Studio (as I do) a new label is auto named as label1, label2
etc. Change that to something meaningfull like userNamePrompt
.
But in contrast to tinstaafl I would still leave the type in, asuserNamePromptLbl
so that I can immediately see in my code what properties etc. are available for that type and what it does in my UI.
That's the problem with conventions almost everyone has his own "brand". Once you adapt a convention it is best you stick to it, certainly if you're working in a team.
Whilst tinstaafl's approach has much to recommend it I personally do something similar to ddanbe. My view is that the tools I use most have simple ways of renaming controls and propogating the changes throughout the code, so the impact of changing the name when the type changes is minimal.
Where I differ from ddanbe is that I put the type as a prefix to the name rather than as a suffix. That makes it easier for me to find when I know I want a label (or combo box or whatever) but I am unsure what I called it. Particularly in an alphabetical list of controls it is easier to find lblUserNamePrompt than UserNamePromptlbl, especially if my memory is playing tricks and it is really called lblLogOnNamePrompt. In an alphabetical list all the labels appear together so I have fewer names to scan to find the one I want.
Assuming you're using the Visual Studio designer, what I do is keep part of the default name and replace the useless number with the same tag as the related control. The tag is chosen based on what the controls do or represent. Often if the controls are bound, the tag would be similar to the property or column I'm binding to. For example:
class Login
{
public string UserName { get; set; }
}
...
Label labelUserName;
TextBox textBoxUserName
...
textBoxUserName.ResetBinding("Text", _login, "UserName");
This way I can easily find controls in the quick search popup. Typically from the code view I don't care as much about the relation between controls as their actual type, so the type is prefixed.
The full name type is verbose compared to something like a Hungarian convention, but the former is easier to remember (not to mention there are variations of Hungarian that can complicate things). I actually like the verbosity as well, in terms of code readability.
In practice, I haven't typically needed the name of label controls. So while it wouldn't be harmful to leave them with the default numbered name, it just feels unclean to me. And clean code is important. ;)
I should mention that I already follow a naming system similar to the ways you guys have mentioned.
I usually name my elements a bit like this: e.g a text box: TbUserInput.
The question was more directed towards how I'd name cosmetic elements, like labels. ddanbe's answer was he most useful in this sense, but thank you for all replies. UPVOTES FOR EVERYONE.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.