• 0

.NET Controls naming convention


Question

Hello, I am new to .NET programming. There is a set of naming convention in Java, for example, methodName for method name, CONTNT for constants. I want to know if there is also a set of naming conventions for .NET controls, such as textbox, labels, data grid...etc?

Thank you very much! :)

Link to comment
https://www.neowin.net/forum/topic/785788-net-controls-naming-convention/
Share on other sites

Recommended Posts

  • 0

You can name them anything you like. But having consistency is a great component.

Examples, for labels I use LBL_#CONTROL# and text boxes TXT_#CONTROL#

Just simple things like that, and if you have a tabbed or multi-window application, you can use something like LBL_TB2_#CONTROL# for a label on the second tab.

Thats how I roll anyway.

  • 0

The way I was taught in college is something like textBoxUserName (for a textbox control) but I completely ignored it. Instead I just use Hungarian notation which is a lot faster yet still easy to interpret. Hungarian notion is simply stuff like lblName for a label, txtName for a textbox, cboName for a combobox, lstName for a listbox, etc... That's a pretty common practice. As for non .NET control naming conventions there's a little guide on MSDN: http://msdn.microsoft.com/en-us/library/xz...28VS.71%29.aspx

This site: http://www.anticipatingminds.com/Content/p...wledgePack.aspx which references that MSDN page seems to suggest that you add the name of the control at the end of the field name. For example, a textbox for a person's first name would be "firstNameTextBox". To me that seems ridiculous as it is extra typing and simple 3 letter abbreviations seem to work perfectly fine.

Edited by dlegend
  • 0

We name our UI controls to be as self documenting as any other variable. The only exception is that they are prefixed with 'ux' indicating they are part of the user experience. We toyed with 'ui' but it didn't look as good depending on the rest of the control name. So if I had a textbox fir a user first name and property to hold the value, I might have something like uxFirstName.Text = myCLass.FirstName. We never use the control type in the control name anymore except in cases of lists and grids and even in those cases, the control name indicates the data, not the control such as uxStateList (combo) or uxMemberClaimsGird (datagridview). The benefit of the 'ux' prefix is that all controls are listed in inteillisense together.

  • 0

Systems Hungarian Notation has really fallen out of favor now. Microsoft officially recommends that you shouldn't use it.

  Quote
Do choose easily readable identifier names. For example, a property named HorizontalAlignment is more readable in English than AlignmentHorizontal.

Do favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

Do not use underscores, hyphens, or any other nonalphanumeric characters.

Do not use Hungarian notation.

http://msdn.microsoft.com/en-us/library/ms229045.aspx

  • 0
  sbauer said:
Systems Hungarian Notation has really fallen out of favor now. Microsoft officially recommends that you shouldn't use it.

Yes, I've heard this as well but I still prefer to use it. Does anyone know why it's not recommended? I think it's simple and effective.

  • 0

I have been using a dirivative of the Hungarian for over a dozen years. Can someone explain the logic on why this format should not be used?

After all, looking at txtFirstName, strFirstName give more info and context that just FirstName. If I am reviewing code and see FirstName how am I to know, on sight, if that is a variable, a control or a function?

  • 0
  jakem1 said:
Yes, I've heard this as well but I still prefer to use it. Does anyone know why it's not recommended? I think it's simple and effective.

It's a form of commenting and comments lie. It's just redundant.

To be honest, I've never understood the love affair with Hungarian notation and .net. Why do you think it's simple and effective?

  • 0

I use the same as garethevans1986

In Delphi I used hungarian. In C# I use things like textBoxFirstName, checkBoxRememberPassword

I basically just delete the number that gets suffixed on the end of the new control and replace it with the text. It makes for some long control names, but I know exactly what something is.

Unfortunatley the design guidelines don't include control naming, so you're stuck coming up with your own.

  • 0
  jameswjrose said:
After all, looking at txtFirstName, strFirstName give more info and context that just FirstName. If I am reviewing code and see FirstName how am I to know, on sight, if that is a variable, a control or a function?

FirstName would be a horrible name for a method. It doesn't even have a verb in it.

  • 0
  sbauer said:
It's a form of commenting and comments lie. It's just redundant.

To be honest, I've never understood the love affair with Hungarian notation and .net. Why do you think it's simple and effective?

If I see a control called txtFirstName I instantly know that it's a textbox that is used to store first names. I can also use the same notation for variables (e.g. strFirstName is a string used to store first names) which makes my code self documenting and easy to read/write. That's what I like about it.

Out of interest, what do you use?

  • 0
  jakem1 said:
If I see a control called txtFirstName I instantly know that it's a textbox that is used to store first names. I can also use the same notation for variables (e.g. strFirstName is a string used to store first names) which makes my code self documenting and easy to read/write. That's what I like about it.

This is what I'm talking about. Completely redundant. strFirstName? Yeah, of course it's a string. It's a first name. What else could it be? It's not going to be a bool. It's not going to be an int.

Descriptive variable names that reveal intent will often save you from the redundancy that is Hungarian notation (and bad code commenting in general).

  Quote
Out of interest, what do you use?

Variable names that reveal intent. That's all.

  • 0
  The_Decryptor said:
Ehh?

First you say it's bad, then it's good, or am I just confused? ("strFirstName" is Hungarian notation)

I'm saying it's bad. I'm saying strFirstName is bad.

  Quote
This is what I'm talking about. Completely redundant. strFirstName? Yeah, of course it's a string. It's a first name. What else could it be? It's not going to be a bool. It's not going to be an int.
  • 0
  sbauer said:
This is what I'm talking about. Completely redundant. strFirstName? Yeah, of course it's a string. It's a first name. What else could it be? It's not going to be a bool. It's not going to be an int.

Descriptive variable names that reveal intent will often save you from the redundancy that is Hungarian notation (and bad code commenting in general).

strFirstName may be a bad example because first name is going to be a string. What about a user ID? It could be a string or an integer for example. strUserID or intUserID works perfectly and reveals usage and intent.

Why are you being so obtuse? At the end of the day this all just comes down to personal/team preference. There are no rules as long as the solution you choose is logical and meaningful. I'm happy to put up with a couple of strFirstName type names to make the most of an intUserID.

  • 0
  sbauer said:
This is what I'm talking about. Completely redundant. strFirstName? Yeah, of course it's a string. It's a first name. What else could it be? It's not going to be a bool. It's not going to be an int.

Descriptive variable names that reveal intent will often save you from the redundancy that is Hungarian notation (and bad code commenting in general).

The 'str' is not redundant, it is there to show it's a string and not a control eg edFirstName would be an edit control.

  • 0
  jakem1 said:
strFirstName may be a bad example because first name is going to be a string. What about a user ID? It could be a string or an integer for example. strUserID or intUserID works perfectly and reveals usage and intent.

1) Once I realize the standard, I would never need to carry the baggage around throughout the entire application.

User user = new User();

user.strUserID = "B192" <-- ugly.

Or 2) I would put my mouse over the variable name.

Or 3) Develop a standard where UserID = int/guid, UserNumber = string

Seriously, though, you're going to add a ton of extra baggage to your code just so you can see what type the ID is without having to think?

  Quote
Why are you being so obtuse? At the end of the day this all just comes down to personal/team preference. There are no rules as long as the solution you choose is logical and meaningful. I'm happy to put up with a couple of strFirstName type names to make the most of an intUserID.

I'm not being obtuse. The original poster asked for advice, and he got a lot of advice that I didn't agree with. Therefore, I'm going to share my opinion. My opinion isn't completely different. Microsoft, Robert Martin (author of Clean Code), and Linus Torvalds all share the same opinion when in comes to Systems Hungarian notation.

I realize it's a team preference. My team used sourcesafe before I came. That, like this, was a team preference, but it certainly wasn't the best option.

  • 0
  Mike said:
The 'str' is not redundant, it is there to show it's a string and not a control eg edFirstName would be an edit control.

Why do you even use IDEs? Use App Hungarian notation for the ui components, but don't pollute other stuff. Or what purpose is the strFirstName serving as a private field within the page or ui form?

  • 0
  sbauer said:
Why do you even use IDEs? Use App Hungarian notation for the ui components, but don't pollute other stuff. Or what purpose is the strFirstName serving as a private field within the page or ui form?

I use IDEs to make the building process easier and so I don't need to manually add new files to be built etc.

The whole 'hover over a variable to see what type it is' is a bad idea. Why? Because it means you (personally) don't know what the variable type is.

The strFirstName variable could be the result of a simple edFirstName->GetText() call and the resultant string could be used to show a message or whatever. If you just had FirstName for the edit control, what would the variable be called that took the string?

  • 0
  Mike said:
The whole 'hover over a variable to see what type it is' is a bad idea. Why? Because it means you (personally) don't know what the variable type is.

That doesn't make any sense. You don't know the type either. You're just guessing the type is the same as the prefix. The prefix is a comment. That's all it is. If someone changed the type on you without refactoring the variable name, you'd be wrong.

  Mike said:
The strFirstName variable could be the result of a simple edFirstName->GetText() call and the resultant string could be used to show a message or whatever. If you just had FirstName for the edit control, what would the variable be called that took the string?

Fine. Break out the Apps Hungarian notation, and prefix all the controls with a ui prefix. string firstName = uiFirstName.Text. That's an OK standard. I would never pollute my code with the typical Systems Hungarian notation crap, though.

Edited by sbauer
  • 0
  sbauer said:
That doesn't make any sense. You don't know the type either. You're just guessing the type is the same as the prefix. The prefix is a comment. That's all it is. If someone changed the type on you without refactoring the variable name, you'd be wrong.

No i'm not guessing, the prefixes are chosen for a reason. They aren't just some random letters. If someone did change the type and didn't change the prefix they would end up with a sore backside.

  sbauer said:
Fine. Break out the Apps Hungarian notation, and prefix all the controls with a ui prefix. string firstName = uiFirstName.Text. I would never pollute my code with the typical Systems Hungarian notation crap.

The 'ui' prefix doesn't help with distinguishing the type. It's a similar case with prefixing global variables so you know that if you change it some place, it won't just be your code that is affected.

  • 0
  Mike said:
No i'm not guessing, the prefixes are chosen for a reason. They aren't just some random letters. If someone did change the type and didn't change the prefix they would end up with a sore backside.

I know they're not some random letters. I get the concept. I just don't believe in it. I think the investment is not worth what you get back.

  Quote
The 'ui' prefix doesn't help with distinguishing the type. It's a similar case with prefixing global variables so you know that if you change it some place, it won't just be your code that is affected.

Yeah, I don't care about that either. I don't want type information in my variable names. It's unnecessary and wasn't what Hungarian notation was designed to be.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Scientists explain how bigger does not mean better for electric vehicles during colds by Sayan Sen Image by Blomst via Pixabay A new study by Cornell University researchers, working with Tompkins Consolidated Area Transit (TCAT), has found that electric buses use a lot more energy in cold weather, especially in places like Ithaca, where the roads are hilly and winters can be harsh. TCAT started testing seven battery-electric buses (BEBs) in 2021 as part of a pilot program funded by a federal grant. Over two years, the buses ran on 41 different routes in Tompkins County.However,t the buses had issues during colder months, with lower driving range and performance. To understand why, researchers looked at real-world data and developed what they called “Optimal Temperature Zone” (OTZ) models—these models show how much energy the buses would have used in ideal temperatures between 16°C and 30°C. When temperatures dropped to between −4°C and 0°C, the buses used about 48.0% more energy, including both power used to drive and energy regenerated through braking, compared to OTZ predictions. Even in the wider range of −12°C to 10°C, energy use still jumped by 28.6%. Half of this extra energy went into heating the batteries themselves. These bus batteries work best at about 24°C, so when it’s cold, they need extra power to warm up before the bus can even get moving. The other major factor was the cabin’s heating system, especially on urban routes where doors open and close often, letting in cold air. “With an all-electric vehicle, the battery is the only onboard energy source,” said Max Zhang, senior author of the study and a professor at Cornell. “Everything has to come from it.” The study also found that regenerative braking—the process that lets the battery recharge a bit while the bus slows down—didn’t work as well in cold conditions. One reason is that these bus batteries are huge, about eight times bigger than typical electric car batteries, and it’s harder to keep the temperature even across all the battery cells. To improve the buses' performance in winter, the researchers suggested a few short-term fixes: parking them indoors to keep them warmer, charging batteries while they’re still warm, and reducing the length of time the doors stay open during stops. On a bigger scale, cities might need to rethink their transit infrastructure. That includes checking how many charging stations they have, whether buses can be kept in heated garages, and how to adjust routes and schedules. “You have to try to optimize the schedule of all of the buses and to consider the capability of your infrastructure – how many charging stations you have, and if you have your own garage,” said lead author and PhD student Jintao Gu. The team found that rural routes, which have fewer stops, use less extra energy in cold weather than urban ones. That could help transit agencies decide which routes are better for electric buses during colder months. “One of the lessons we’ve learned is that these buses should be designed for the whole country, including states with colder climates,” said Zhang. “But any lessons are good lessons. This helps us learn as a society and do better.” Source: Cornell University, ScienceDirect This article was generated with some help from AI and reviewed by an editor. Under Section 107 of the Copyright Act of 1976, this material is used for the purpose of news reporting. Fair use is a use permitted by copyright statute that might otherwise be infringing
    • Appears to be 150W PSU (Core Ultra 9) so most power delivery ports wouldn't even support it.
    • I wasn't implying people should be forced to use a single launcher. I prefer user choice. If Windows includes a decent game launcher, great, people might choose to use it if they want to. If it sucks, no one will use it. I would be completely against anyone being forced in that direction, just like I am against being forced to use 3rd party launchers if I choose to use Steam.
    • Sounds good, but that'd require Microsoft to develop and API of some sort and then get all the developers to support it... but everyone knows that while others will support Microsoft, Microsoft won't support itself and will kill off the feature... again. Microsoft has tried this trick in Windows 9x era, they tried it with the games library in Vista, they tried a big push for Games for Windows Live, and then again in Windows 8 with the WPA apps via their mobile/windows phone eco system. Now they're trying it again, and it's lets not forget that this isn't a push to make PC gaming better. It's not. To do that they need to provide at least the same level of quality and feature set of Steam, otherwise why else are gamers going to not use Steam. Right now Xbox app and everything Microsoft centric around the PC gaming front is exclusively for their new Xbox brand push to make everything an Xbox. Your Toaster, your cat, your PC, your VR headset, everything is a Xbox and that'll last for this generation of Xbox now probably. Then, like Microsoft always has done and will do, they'll drop it like a hot potato and everyone will be left crying. Point in case, bringing Xbox games to the ROG handheld, their entire point of this... They're marketing it as if it's an Xbox console in a handheld, yet, it's not. There are going to be Xbox gamers who think, they'll be able to pickup their Xbox one games and play them on a handheld like Nintendo and Steam Deck users... except they're going to quickly find out that their Xbox game library is almost entirely missing or games they've already purchased on the Xbox need to be purchased again on the 'this is an Xbox' handheld.
  • Recent Achievements

    • Dedicated
      tesla maxwell earned a badge
      Dedicated
    • Dedicated
      Camlann earned a badge
      Dedicated
    • Week One Done
      fredss earned a badge
      Week One Done
    • Dedicated
      fabioc earned a badge
      Dedicated
    • Week One Done
      GoForma earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      637
    2. 2
      Michael Scrip
      224
    3. 3
      ATLien_0
      219
    4. 4
      +FloatingFatMan
      142
    5. 5
      Xenon
      135
  • Tell a friend

    Love Neowin? Tell a friend!