• 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

    • Microsoft removes PowerShell 2.0 from Windows 11 in build 27891 by Taras Buria Microsoft has released a new Windows 11 preview build from the Canary Channel. Build 27891 is out with several improvements and fixes, a new feature for the Microsoft Store, and the removal of PowerShell 2.0, which is now deprecated. Microsoft deprecated PowerShell 2.0 all the way back in Windows 10 version 1709. Last month, it issued a reminder about it, and now, PowerShell 2.0 is gone from the latest Windows 11 Canary builds. Microsoft says it will publish more information about PowerShell 2.0 removal in the upcoming update for Windows 11. Also, Microsoft is rolling out a new update for the Microsoft Store. Version 22406 is rolling out to Windows Insiders in the Canary and Dev Channels, offering the ability to install a product right from the Store's home page, as seen in the screenshot below: Here is what was fixed: [General] We fixed the issue causing the “Reset this PC” option under Settings > System > Recovery to not work after upgrading the last few Canary Channel builds. Fixed the underlying issue which was causing the taskbar to unexpectedly not showing acrylic material after upgrading to the latest Canary builds. This also impacted a few other scenarios, leading to unexpected black or white in some UI. Fixed an underlying issue believed to be the cause of some Insiders seeing Windows update downloads to get stuck at 2% recently. Fixed a few more languages including Vietnamese and Arabic that were still having issues with certain characters not rendering correctly for Insiders after the latest builds, causing nonsense to display in places like Task Manager and more. This impacted characters outside of A-Z. [File Explorer] Fixed an issue where if you opened the “…” menu in the File Explorer address bar to show the full list of folders for the current path, the dropdown might be cut off and the bottom of it inaccessible. [Settings] Fixed an issue in the previous build which could cause Settings to crash when opening microphone properties under Settings > System > Sound. Fixed an underlying issue related to Bluetooth which could cause Settings or Quick Settings to crash on launch for some people. [Windowing] Fixed an issue which was causing the window minimizing animation to not display correctly in the previous flight. [Task Manager] Fixed an issue where the CPU graphs in the Performance page were still using the old CPU utility calculations. Fixed an issue where after adding the new CPU Utility column, you might notice that System Idle Process always showed as 0. [Audio] Fixed an issue which could cause all system sounds to stop working (for example notification alert sound and the sound that plays when clicking the volume slider in quick settings), although audio in general was working on your PC. [Other] Fixed an underlying issue which was causing fonts in certain app menu items to unexpectedly appear corrupted or overlapped for some people. This also impacted typing in Word – where when using Hebrew a period may unexpectedly show as a 3, and in Thai typing space may show a 2. Fixed an underlying issue which could cause the playback controls in Media Player to become distorted in the latest Canary flights. Fixed an underlying issue believed to be the cause of LDAP queries from apps to take an unexpectedly long time in the previous flight. Fixed an issue which could cause print previews to appear slightly blurry in recent Canary flights. Here is the list of known issues: [General] [IMPORTANT NOTE FOR COPILOT+ PCs] If you are joining the Canary Channel on a new Copilot+ PC from the Dev Channel, Release Preview Channel or retail, you will lose Windows Hello pin and biometrics to sign into your PC with error 0xd0000225 and error message “Something went wrong, and your PIN isn’t available”. You should be able to re-create your PIN by clicking “Set up my PIN”. [Settings] [NEW] We’re investigating an issue in this build which could cause Settings to crash when interacting with the options under Settings > System > Power & Battery. [Remote Desktop] [NEW] You may see extreme graphical distortion and rendering issues using remote desktop on Arm64 PCs in this build. You can find full release notes for build 27891 in a post on the official Windows Blogs website.
    • Sounds like corporate spamming being painted as a "feature"...so long as it can be blocked like any other random creep messaging you, no biggie.
    • Don't really like these kinds of games but that song is nice.
    • SVE: easy video editor for trimming and cropping by Razvan Serea SVE SimpleVideoEditor is a lightweight, open-source video editor designed with simplicity and speed in mind. Built using Python and featuring a clean graphical user interface, it allows users to perform essential video editing tasks without the complexity of professional software. The tool supports trimming clips, cropping video frames, and extracting audio from video files, making it perfect for quick edits and basic media tasks. Its intuitive design ensures that even beginners can navigate and use it effectively without a steep learning curve. SVE SimpleVideoEditor doesn’t require heavy system resources or complicated installation steps, making it accessible on a wide range of systems. Ideal for casual users or anyone looking for a minimal yet functional editing tool, it offers a straightforward experience focused on getting the job done with minimal hassle. While more advanced tools like Shotcut offer extensive editing features and LosslessCut excels in ultra-fast, lossless trimming, SVE stands out for its simplicity and ease of use. Download: SimpleVideoEditor v2025.06.29 | 87.7 MB (Open Source) Links: SimpleVideoEditor Website | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
  • Recent Achievements

    • Week One Done
      Devesh Beri earned a badge
      Week One Done
    • Week One Done
      956400 earned a badge
      Week One Done
    • First Post
      loose_observer earned a badge
      First Post
    • Week One Done
      BeeJay_Balu earned a badge
      Week One Done
    • Week One Done
      filminutz earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      470
    2. 2
      ATLien_0
      159
    3. 3
      +FloatingFatMan
      151
    4. 4
      Nick H.
      66
    5. 5
      +thexfile
      62
  • Tell a friend

    Love Neowin? Tell a friend!