.net Naming Conventions and Programming Standards - Best Practices

Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

.net Naming Conventions and Programming Standards - Best Practices

This article is the single most popular bit of content from my old site and blog, bar none. While I think books such as the .NET Framework Design Guidelines by Krzystof Cwalina and Brad Abrams do a better job explaining all the standards, I've kept this page up for quick reference and to support the schools and individuals currently using it.

Common .NET Naming Conventions

These are the industry-accepted standard naming conventions for C# and VB.NET programs. For additional information, please see the MSDN help documentation and the book referenced above. While individual naming conventions at organizations may vary (Microsoft only suggests conventions for public and protected items), the list below is quickly becoming the de-facto standard in the industry. Please note the absence of Hungarian Notation. These naming standards should find their way into all of your .NET development, including ASP.NET Web applications, WPF, Silverlight and Windows Forms applications.

Note that while this document predates the online and printed standards documentation from Microsoft, everything below which indicates it is based on .NET library standards is consistent with that documentation and Brad's book. In areas where Microsoft has not provided guidance (Microsoft generally doesn't care what you do in private/non-exposed code. In fact, they aren't even consistent in their internal code in the .NET framework), de facto standards have emerged, and I have captured them here.

The "ux" naming convention for controls is something I have added and found to be helpful in Windows Forms, but not so much in Silverlight and WPF. It is not based on any official standards, but instead based upon a multitude of projects by my teams and others, as well as on-line discussions on the topic. While I strongly recommend that you follow Microsoft guidelines when present, I encourage you to try out the items marked as extensions below and see how they work for you before committing to them.

Type	Standard / Convention	Example
Namespaces	Standard Based Upon Microsoft .NET Library Standards Pascal Case, no underscores. Use CompanyName.TechnologyName as root. If you don't have a company, use your domain name or your own initials. Note that any acronyms of three or more letters should be pascal case (Xml instead of XML) instead of all caps. Why: This convention is consistent with the .NET Framework and is easy to read.	`AppliedIS.TimeCard.BusinessRules` `IrritatedVowel.Controllers` `PeteBrown.DotNetTraining.InheritanceDemo` `PeteBrown.DotNetTraining.Xml`
Assemblies	Standard Based Upon Microsoft .NET Library Standards If the assembly contains a single name space, or has an entire self-contained root namespace, name the assembly the same name as the namespace. Why: This convention is consistent with the .NET Framework and is easy to read. More importantly, however, it keeps your assembly names and namespaces lined up, making it really easy to figure out what is any particular assembly, and what assembly you need to reference for any given class.	`AppliedIS.TimeCard.BusinessRules.dll` `IrritatedVowel.Controllers.dll`
Classes and Structs	Standard Based Upon Microsoft .NET Library Standards Pascal Case, no underscores or leading "C" or "cls". Classes may begin with an "I" only if the letter following the I is not capitalized, otherwise it looks like an Interface. Classes should not have the same name as the namespace in which they reside. Any acronyms of three or more letters should be pascal case, not all caps. Try to avoid abbreviations, and try to always use nouns. Why: This convention is consistent with the .NET Framework and is easy to read.	`Widget` `InstanceManager` `XmlDocument` `MainForm` `DocumentForm` `HeaderControl` `CustomerListDataSet (typed dataset)`
Collection Classes	Standard Based Upon Microsoft .NET Library Standards Follow class naming conventions, but add Collection to the end of the name Why: This convention is consistent with the .NET Framework and is easy to read.	`WidgetCollection`
Delegate Classes	Standard Based Upon Microsoft .NET Library Standards Follow class naming conventions, but add Delegate to the end of the name Why: This convention is consistent with the .NET Framework and is easy to read.	`WidgetCallbackDelegate`
Exception Classes	Standard Based Upon Microsoft .NET Library Standards Follow class naming conventions, but add Exception to the end of the name Why: This convention is consistent with the .NET Framework and is easy to read.	`InvalidTransactionException`
Attribute Classes	Standard Based Upon Microsoft .NET Library Standards Follow class naming conventions, but add Attribute to the end of the name Why: This convention is consistent with the .NET Framework and is easy to read.	`WebServiceAttribute`
Interfaces	Standard Based Upon Microsoft .NET Library Standards Follow class naming conventions, but start the name with "I" and capitalize the letter following the "I" Why: This convention is consistent with the .NET Framework and is easy to read. It also distinguishes classes from interfaces, where (unlike in VB6) are truly different beings. This avoid name collisions as well, as it is quite common to have IFoo and a class named Foo that implements IFoo.	`IWidget`
Enumerations	Standard Based Upon Microsoft .NET Library Standards Follow class naming conventions. Do not add "Enum" to the end of the enumeration name. If the enumeration represents a set of bitwise flags, end the name with a plural. Why: This convention is consistent with the .NET Framework and is easy to read.	`SearchOptions (bitwise flags)` `AcceptRejectRule (normal enum)`
Functions and Subs	Standard Based Upon Microsoft .NET Library Standards Pascal Case, no underscores except in the event handlers. Try to avoid abbreviations. Many programmers have a nasty habit of overly abbreviating everything. This should be discouraged. We're not designing license plates or being charged by the letter :) Functions and subs must differ by more than case to be usable from case-insensitive languages like Visual Basic .NET Why: This convention is consistent with the .NET Framework and is easy to read.	VB: `Public Sub DoSomething(...)` C#: `public void DoSomething(...)`
Properties and Public * Member Variables	Standard Based Upon Microsoft .NET Library Standards Pascal Case, no underscores. Try to avoid abbreviations. Members must differ by more than case to be usable from case-insensitive languages like Visual Basic .NET. Why: This convention is consistent with the .NET Framework and is easy to read.	VB: `Public Property RecordId As Integer` C#: `public int RecordId`
Parameters	Standard Based Upon Microsoft .NET Library Standards Camel Case. Try to avoid abbreviations. Parameters must differ by more than case to be usable from case-insensitive languages like Visual Basic .NET. Why: This convention is consistent with the .NET Framework and is easy to read.	VB: `ByRef recordId As Integer` C#: `ref int recordId`
Procedure-Level Variables	Standard Based Upon De facto Industry-Accepted Practices Camel Case Why: This convention is consistent with the .NET Framework and is easy to read. It also avoids naming collisions with class-level variables (see below)	VB: `Dim recordId As Integer` C#: `int recordId ;`
Class-Level Private and Protected Variables	Standard Based Upon De facto Industry-Accepted Practices Camel Case with Leading Underscore. In VB.NET, always indicate "Protected" or "Private", do not use "Dim". Use of "m_" is discouraged, as is use of a variable name that differs from the property by only case, especially with protected variables as that violates compliance, and will make your life a pain if you program in VB.NET, as you would have to name your members something different from the accessor/mutator properties. Of all the items here, the leading underscore is really the only controversial one. I personally prefer it over straight underscore-less camel case for my private variables so that I don't have to qualify variable names with "this." to distinguish from parameters in constructors or elsewhere where I likely will have a naming collision. With VB.NET's case insensitivity, this is even more important as your accessor properties will usually have the same name as your private member variables except for the underscore. As far as m_ goes, it is really just about aesthetics. I (and many others) find m_ ugly, as it looks like there is a hole in the variable name. It's almost offensive. I used to use it in VB6 all the time, but that was only because variables could not have a leading underscore. I couldn't be happier to see it go away. Microsoft recommends against the m_ (and the straight _) even though they did both in their code. Also, prefixing with a straight "m" is right out. Of course, since they code mainly in C#, they can have private members that differ only in case from the properties. VB folks have to do something else. Rather than try and come up with language-by-language special cases, I recommend the leading underscore for all languages that will support it. If I want my class to be fully CLS-compliant, I could leave off the prefix on any C# protected member variables. In practice, however, I never worry about this as I keep all potentially protected member variables private, and supply protected accessors and mutators instead. Why: In a nutshell, this convention is simple (one character), easy to read (your eye is not distracted by other leading characters), and successfully avoids naming collisions with procedure-level variables and class-level properties.	VB: `Private _recordId As Integer` C#: `private int _recordId ;`
Controls on Forms	An Extension to the Standards May 2009 update Note that I still consider this useful in many respects, especially for intellisense grouping, but have backed away from using this in recent projects, specifically Silverlight and WPF. I still use an appropriate classification suffix such as Field or Label (but not an actual control type) so that I can differentiate between, say, the last name field and the label for it. Examples would be LastNameField, LastNameLabel, NextPageNavigation, PreviousPageNavigation. The classifications you pick will need to make sense to you, and also allow for signficiant flexibility for the designer of the UI to change the control type in Xaml without you having to change the name in the storyboards (runtime checked), code behind (compile-time checked), and control lookups in code behind (runtime checked). I backed away simply because it didn't look right in generated member variables in my applications, or in the x:Name properties in Xaml. It was a code smell issue, albeit a minor one. Note also that in Silverlight and WPF, I only name controls which need to be named because they are used in the code behind or are referred to from a storyboard or relative binding. The name is the primary contract between the code and the visual design, and you want to keep that contract as small as possible. Note that I have seen the "ux" prefix in example code on the net, and from Microsoft. Some folks still find it useful. You'll need to make that decision for yourself. I do not use the ux prefix when working in XAML-based uI, like Silverlight and WPF. Original Information from 2002 In recent projects (since 2002 or so), I have taken to a single prefix for all my UI controls. I typically use "ux" (I used to use "ui", but it wasn't set apart well in intellisense). "ux" comes from my usual design abbreviations where it means "User eXperience", which has also since become a popular acronym. I have found this to be extremely helpful in that I get the desired grouping in the intellisense even better than if I use "txt", "lbl" etc. It also allows you to change combo boxes to text boxes etc. without having to change the names - something that happens often during initial prototyping, or when programming using highly iterative agile/xp methodologies. Why: This convention avoids problems with changing control types (textboxes to drop-down lists, or simple text box to some uber textbox, or text box to date picker, for example), and groups the items together in intellisense. It is also much shorter than most Hungarian conventions, and definitely shorter and less type-dependent than appending the control type to the end of the variable name. I will use generic suffixes which allow me enough freedom to change them around.	`"ux" prefix` `uxUserIdField, uxHeaderLabel, uxPatientDateOfBirthField, uxSubmitCommand` `no "ux" prefix` `LastNameField, LastNameLabel, SubmitCommand, NextPageNavigation`
Constants	Standard Based Upon Microsoft .NET Library Standards Same naming conventions as public/private member variables or procedure variables of the same scope. If exposed publicly from a class, use PascalCase. If private to a function/sub, use camelCase.. Do not use SCREAMING_CAPS Why: This convention is consistent with the .NET Framework and is easy to read. A sizable section of the Framework Design Guidelines is dedicated to why they chose not to go the SCREAMING_CAPS route. Using SCREAMING_CAPS also exposes more of the implementation than is necessary. Why should a consumer need to know if you have an enum, or (perhaps because they are strings) a class exposing public constants? In the end, you often want to treat them the same way, and black-box the implementation. This convention satisfies that criteria.	`SomeClass.SomePublicConstant` `localConstant` `_privateClassScopedConstant`

* Public class-level variables are universally frowned upon. It is considered to be a much better practice to use property procedures (accessors and mutators) to provide read and/or write access to a private member variable. If you must expose a member variable to other classes using "Public", follow the property naming conventions, but don't complain if your guilty conscience keeps you up at night ;-).

You Can find the standards for publicly exposed classes/properties etc at MSDN . If you want to run a tool to validate your code for public standards and required practices, download FXCop or use the analysis tools in Visual Studio.

Why Hungarian Has Fallen Out of Favor with .NET

With his simple question in my guestbook, Andrew Coupe inspired me to write this little blurb here explaining why I feel that Hungarian Notation has outlived its usefulness. If you're sticking to Hungarian Notation in .NET, waffling, or just plain curious - read on.

True Hungarian Notation is a naming convention invented by Charles Simonyi from Microsoft back in the 70s. (For more information on its origins, see this funny article) Back in the day, one of the more promising versions of Hungarian Notation was used in a way that indicated the purpose or logical type of the variables rather than the language-specific type. For example, instead of indicating something was an int, it would be specified that it was an Id or a Quantity. When Hungarian was used this way, it was very useful, especially in languages where variable names were limited in length.

Shortly after the notation started being used, developers came up with standard language-specific data-type based prefixes. I remember when I worked in C/C++, we had things such as "rgsz" meaning an array of zero-terminated strings (rg is short for"reference to a graph" - an array in C/C++). This was useful for a while, but the prefixes became unwieldy in both in length and in understanding the permutations and combinations; you ended up with things not too far from rgszxyzpdqOrderNo. Think that's a stretch? Imagine what the name of a variable that contained a long pointer to an array of arrays of long pointers to some particular structure looked like when you mapped out the full prefix. Yes, we really did have the occassional variable like that in our programs, especially the database engine I worked on.

Then along came Visual Basic. This great rapid application development tool introduced a lot of programmers to Windows programming. Many them were brand new to programming, and gave their variables meaningless or less than helpful, and almost always inconsistent names. In response to this influx of bad code, good VB developers started to use two different variations of the Hungarian naming conventions. One was a traditional "as many letters as needed" set with prefixes such as "s" for String, "i" for Integer, and sometimes things like "arrl" for an array of longs. The second school standardized on three letters for all prefixes "str" for String, and "int" for Integer being two examples.

Some people took the conventions to extremes, and did silly things like prefix database table names with "tbl", stored procedures with "P", VB classes with "C" or "cls", and function names with the Hungarian for their return type. That was and is still just pure silliness, IMHO. I do, however, think that "I" in front of an interface is important as interfaces need to be treated very differently from classes.

During this time, VB4 and eventually VB5 and VB6 came out. VB4 introduced classes and some object-oriented language features to these developers. Developers needed to remember to use "Set" when assigning object variables, and had to remember to set them to "Nothing" when they were done with them. To assist in remembering to do this, developers would prefix all their object variables with "obj" or "o". Typical code around this time was nothing but a ton of variables with names like objResults and oHenry. It looked just a bit odd, and wasn't particularly helpful.

Those of us who worked a lot with COM objects in Visual Basic realized that the prefixes made no sense in public interfaces. In fact, they looked plain awful. Many of us adopted conventions that stated that anything exposed via COM would not have any prefixes whatsoever. That included parameters, functions, classes, etc. This was inline with what Microsoft and most 3rd-party vendors did with all the COM libraries and ActiveX controls they provided.

At the same time, those of us working on large projects noticed a definite laziness on the part of some other programmers (you know who you are! <g>) when it came to updating the variable prefixes when they changed a variable from, say, an Integer to a Long. This caused far more confusion than was worth. When coupled with the huge multi-page lists of "all the prefixes" for every possible type you could think of, Hungarian started to get in the way more than it helped.

Along comes .NET and just about everything is an object or can be boxed as such, and everything public is exposed to other languages - languages which may not use the same names for the variables we use (this was the same issue we had when writing for COM). If I want to know a variable's type, I can hover over it with the mouse in the VS.NET IDE. If I want to know a variable's use, I simply look at the well-worded variable name.

Now, rather than memorizing lists of prefixes, or prefixing everything with "obj", programmers are able to concentrate on the purpose of the variable rather than the underlying type. This alone has increased programmer productivity by removing the requirement to perform that mental prefix lookup - which for some of us was like a SQL Server full-table scan <g>.

Since the .NET languages were a reasonably clean break from the old versions, it made sense for Microsoft and .NET developers to also change the expected naming conventions at the same time. They knew the adoption of the new conventions would be more likely (and less painful) with the platform shift.

.NET variables and types can have extremely long names, names that can describe the purpose of a variable rather than the underlying type. We don't have to pack as much meaning as possible into just a few letters. Control-space makes typing the long names completely painless, and the long names really assist in understanding and documentation.

Some people still stick to the old Hungarian notation, but those are the hold-outs. Sharing code with them becomes frustrating as the conventions have to be all modified when you do so. If everyone follows the Microsoft-recommended .NET conventions, information exchange and collaboration becomes much easier :-) If you are one of these hold-outs, and have good reasons for sticking to Hungarian, I'd love to hear from you via the contact link at the bottom of this page.

UI controls are something that are still in flux when it comes to conventions. The reason Hungarian is still often used for them is to ensure they are grouped in intellisense. Hungarian is definitely not perfect for this, but it works.

222 comments for “.net Naming Conventions and Programming Standards - Best Practices”

Reply
Daniel M. Grassicksays:
Thursday, July 17, 2003 at 12:40:47 AM
I was doing the usual frustrating sifting through results from a Google search that I did on naming conventions and I found your site. Your summary is great and I mentioned it in a forum on "http://windowsforms.net". This same site has an impressive real world sample application called "TaskVision" and the prefixes "m_" and "c_" were used in the VB.NET source for private variables and constants respectively. In the forum I asked if there was any interest in establishing a list of recommended prefixes for Windows Forms controls and perhaps data controls. I would certainly be interested!

Daniel
Reply
Tihomir Pupeksays:
Wednesday, July 23, 2003 at 10:11:02 AM
Nice site. I've been looking for VB .NET naming conventions, but the birds, photos and other stuff here attracted me as well. :)
Reply
Adriansays:
Wednesday, July 30, 2003 at 8:40:01 AM
Thanks a lot for your .NET programming standards, it's a good collection. Maybe you could add a list with suggestions for naming the visual controls / components included in VS (using the hungarian notation).

Cheers!
Adrian
Reply
Jason Mercersays:
Thursday, July 31, 2003 at 8:42:58 AM
Very useful document! But I'm not sure about the naming conventions for assemblies... Company.Technology.dll makes sense, but Company.Technology.exe doesn't. I prefer to keep it shorter to one word...

Just a thought...
Reply
Noocytesays:
Wednesday, August 6, 2003 at 12:30:22 AM
Had a look at your naming conventions for .Net programming. Liked them, and using them now! Thanx! :)
Reply
Marc Scheunersays:
Monday, August 11, 2003 at 3:02:22 AM
Found you through a C# newsgroup posting (on naming conventions) - very nice web site, very attractive, and very intriguing (technically) - that's exactly what I'd like to do (C# - ASP.NET - SQL Server 2000 - house my own server), trouble is, the prices for DSL access with your own static IP are just beyond belief where I live (Switzerland), unfortunately :-(

Excellent stuff you got here! Keep it up.

Happy hacking....

Marc
Reply
Vlad Bezdensays:
Thursday, September 25, 2003 at 10:15:27 AM
Great summery of Name Conventions. I was looking for long time similar to what you've done. Thanks a lot. Great job.

Sincerely,
Vlad.
Reply
John Kennedysays:
Tuesday, October 7, 2003 at 2:54:11 PM
Saw your post on programming standards on the VisBas-L list today. I have occasionally toyed with the idea of learning VB but never got farther than that. Your post made excellent reading for a rank newbie (who may always remain one, but who plays with MS-ACcess from time to time).
Reply
Edgar D'Souzasays:
Friday, October 10, 2003 at 5:02:16 AM
Pete,
I used to be a fan of yours back on VISBAS-L and VBDATA-L; things having changed in my life, I no longer frequent those lists (can't afford the bandwidth from home :) but in the interests of getting to .NET (sometime, when I finish with my current spate of ASP3.0 and PHP work) I subscribed to the dotnet lists at DevelopMentor. Was pleasantly surprised to find you there, and to visit your site.

The code samples (HttpModule, in particular) and Standards, make for good reading, stuff that I will memorize :-) and hope it sticks!

Your programming wallpapers - Wow! That looks like a lot of painstaking time blending all those fractals and applying the flares, slants and what-not!
My compliments on an experience I enjoyed - your site!

Thanks,
Edgar.
Reply
Dansays:
Wednesday, October 22, 2003 at 4:40:30 PM
We (team of two) just started using VB.Net and decided to implement a naming standard. What you provided is quite helpful.

Thanks,

Daniel Hochee
DataPro Solutions
Spokane, WA
Reply
Chinnakaruppansays:
Monday, December 15, 2003 at 6:31:16 AM
Thanks it is really useful for me to develop the C# standards for my project.

Regards
Chinnakrauppan
Reply
Helensays:
Wednesday, January 14, 2004 at 10:42:58 PM
Good concise summary of .net naming conventions.
A reference/link for the Forms Controls modified Hungarian prefixes would be useful. I also note that the prefixes are in lowercase - making the name Camel Case, which is otherwise only used for private/local variables.
Reply
Donsays:
Thursday, January 15, 2004 at 11:04:15 AM
When naming variables, I have found much value in first stating the scope of the variable (a=argument;l=local;i=instance) and its type (s=string;n=numeric;b=boolean;d=date).

After reviewing your document on .NET Standards and Best Practices, I have revised this variable naming convention to include an underscore when naming instance variables to indicate if it's public, private, or protected. Granted, I will seldom if ever have public instance variables.

This convention covers the most used data types in a very general sense, and helps quite a bit when I go back to review a function that I haven't seen since the last time I slept.

What are your thoughts to this?
Reply
Abhijeet Devsays:
Thursday, February 5, 2004 at 2:55:38 AM
I was looking for compact (n correct) .NET coding conventions for one of the teammates, I am sure he wont read the whole fxcop. These guidelines were very helpful.
Thanx
Reply
Billysays:
Tuesday, February 17, 2004 at 8:13:41 PM
AWESOME!

Thank you so much for the simple list of .NET naming conventions!!!
Reply
Mary Fryesays:
Thursday, February 19, 2004 at 2:28:12 AM
I followed a link to this site from an email through helpwithvb. There is a debate about using Hungarian Notation. Some seem to think that Microsoft is trying to say you can not use it at all, and that Microsoft is trying to force programmers to use a notation that MS wants. I have put your site on my favorites list, thanks for creating it. It seems to have some very useful and pratical information.
Mary
Reply
Betasays:
Friday, February 27, 2004 at 8:15:03 AM
The DotNet naming conventions are very useful! Thanks!
Reply
jnansays:
Tuesday, March 2, 2004 at 3:49:04 PM
found in googlen when searching for .net standards
nice site.
nice wall papers too.I am downloading a few.
Reply
Mark Broadbentsays:
Tuesday, March 30, 2004 at 10:14:15 AM
thanks for taking the time out with this information. I have tried for a while to find info on .net and general naming standards and your info is very useful. Hopefully one day the editors will enforce/ generate these conventions on the fly.
Reply
Jenny Quinnsays:
Tuesday, March 30, 2004 at 10:51:23 AM
I found your naming conventions page very helpful. Thanks.
Reply
Gubersays:
Tuesday, March 30, 2004 at 1:02:15 PM
Good site !
The naming conventions for .NET ate very usefull for me !
And after my work, I get some Wallpapers !!

Good job !
Reply
John Toblersays:
Thursday, April 1, 2004 at 10:51:31 AM
Marc Clifton linked to your C# programming standards page from http://aut.tigris.org/styleGuidelines.htm and I browsed your wallpaper section. You have some really cool wallpapers.

Thanks,

John Tobler
Reply
David Byrdsays:
Friday, April 2, 2004 at 3:25:25 PM
Just wanted to say thanks. I use your .NET programming standards page frequently and it's a great help.

David
Reply
Cesar Mascarinasays:
Saturday, April 3, 2004 at 6:25:07 AM
Keep on the good work of providing standards for the sake of uniformity. Can we use these as appendixes to our future systems development projects? It is a way of providing documentation of what standards were used in the development process. Will you require payment of royalties?
Reply
Jennysays:
Thursday, April 22, 2004 at 4:52:48 PM
I got here doing a search for .NET standards. Thanks for the info. I love the picture you took on a foggy forest morning. It looks like a woods behind my cabin in northern Michigan. I put it on my desktop, with an olive green scheme, and a midnight green frame. Thanks :)
Reply
Stephen Mooresays:
Tuesday, April 27, 2004 at 3:10:45 AM
.net programming standards page was very helpful
Reply
Andrewsays:
Saturday, June 5, 2004 at 12:16:02 AM
Hi Pete. Any thoughts on why Hungarian is going out of style?
Reply
Ladar Levisonsays:
Friday, June 25, 2004 at 10:44:08 AM
We use your .NET naming conventions here at the office. Your site is actually referenced in our policies.

http://www.imaginesolutions.com
Reply
Randal Fullersays:
Wednesday, July 14, 2004 at 11:08:12 AM
This is a great set of .NET standards you've compiled. I am planning on incorporating some of your information into our forthcoming .NET coding standards. As the lead developer, I am tasked with compiling some sort of standards for our upcoming .NET web rewrite and I am using this information as the foundation for our standards directive.

Thanks for all of your effort.

Randy Fuller
Senior Software Developer
RealEC Technologies
9800 Richmond Ave, Suite 100
Houston, TX 77042
713-273-7306
Reply
Alin Hanghiucsays:
Tuesday, July 20, 2004 at 10:57:38 AM
i found your .net naming conventions page helpfull :)
Reply
John Horburysays:
Sunday, July 25, 2004 at 2:46:09 PM
V. usefull section on .NET naming conventions. I particularly agree with the use of a leading _ rather than just camel case.
Reply
Payton Byrdsays:
Tuesday, August 3, 2004 at 1:53:30 PM
I couldn't disagree with you more on Hungarian notation. The myriad of types in .Net has created a real problem where teams of developers have one person working with doubles while another works with decimals, then when you put the two together you loose data! The maintenance programmer then has to go out and figure out where the dataloss is occurring and correct it. This is just one of dozens of examples of how using Hungarian notation helps code maintainers.

Take a look at my blog entry on the subject:

http://blogs.ittoolbox.com/visualbasic/dotnet/archives/000583.asp
Reply
Christopher Harnettysays:
Friday, August 6, 2004 at 5:40:24 AM
I found your site by searching on "c# standards" in Google. I am new to .NET and my main area of interest is in writing an automated build and deploy tool. Your links section is especially useful - please keep expanding it.
Reply
Sverresays:
Monday, August 9, 2004 at 4:25:22 AM
Searched for "c# variable naming conventions" (without the quotes) - found just what I searched for on your site.
Reply
Bobsays:
Sunday, August 15, 2004 at 6:41:56 PM
I find the discussion about hungarian notation and .NET very usefull!
Reply
Dansays:
Wednesday, August 18, 2004 at 2:03:59 PM
HI!
Your take in Hungarian notation is interesting. In the end, I think that it is still useful for the vast majority of people who program, especially because they are not exposing their code to others. Their standards can remain internal standards without worrying about offending anyone.

The one big miss in your assessment I think (or maybe I missed it!) was that IntelliSense is really the reason Hungarian notation is falling out of favor. If a company used Hungarian Notation to identify usage of a variable, the Intellisense will often provide the same information. You are right in saying that Hungarian notation helps keep things grouped in intellisense, but the intellisense does so much more, providing information about types, number of params, etc., that cannot be gleaned from the name alone.

As for Microsoft's standards: I think they are just o.k. They are clearly policically motivated (designed to help woo Java developers to C#). Although they pretend to abandon Hungarian notation, they still use it when the need arises (I for Interface is an obvious example - also appending Collection or EventArgs to a name to identify purpose may be considered an expanded form of Hungarian notation). Also, since the MS standards do not specify conventions for local or private variables, they are vastly incomplete (in a typical program, more than half of the identifiers do not appear in the metadata of the assembly). This being the case, Hungarian notation is likely to be around for a while, especially in VB circles, since it helps address scope and usage issue with private and local identifiers. Just my take on things...

One last thing: I wanted to make you aware of our own naming convention enforcement tool, Standards Master 2004. It supports Hungarian Notation, Pascal Case, camel-case, MS Standards or whatever else is needed, plus offers a whole bunch of other features to aid with other standards enforcement. We think it is a much better tool for naming convention enforcement than FxCop because it gives access to the local and private variables and can automatically fix most errors in the source code for you. If you haven't already, check it out - you may find it useful. http://www.flexisoftsolutions.com.

Thanks for listening!
Dan
Reply
Zain Saeedsays:
Monday, August 23, 2004 at 4:00:30 PM
Using this as the basis for defining our local programming standards.
Great help as you managed to separate out architecture from programming standards.
Thanks
Reply
Zain Saeedsays:
Monday, August 23, 2004 at 4:04:44 PM
Didnt notice you guys cared so much about hungarian notation but if you are interested have a look at the following book and in particular about Hungarian Notation:

http://mindprod.com/unmain.html
Naming->Section29
The whole book discusses how to write unmaintainable code.
Reply
Bill Waltmansays:
Wednesday, September 15, 2004 at 7:51:40 AM
Google. Thanks. I am researching programming standards for a project and really liked you thoughts.

Bill Waltman
Reply
Jasesays:
Thursday, September 16, 2004 at 2:49:33 AM
I liked your section on standards and have added a link to it from my blog for my dev team. Thanks!
Reply
Fareeth ahamedsays:
Monday, October 25, 2004 at 2:05:21 AM
very much satisfied when i started searching for .net coding standards
Reply
phil lertorasays:
Wednesday, November 10, 2004 at 1:25:12 PM
If you are not in favor of prefixing variable names, then please explain how the following makes sense.

dim Person as DataSet

do a bunch of things with the dataset

realize you need to grab a DataTable into a variable

dim PersonTable as DataTable
PersonTable = Person.Tables(0)

So, IMHO, you have created a variable qualification (in this case a suffix) on demand. Only because you need to differentiate a dataset from a datatable did you decide to Suffix your variable name with the word table. Had you not had the conflict, you would have happily called either Person.

On demand qualification can't be predicted. It is not a standard. It's not reliable. If you are writing code to examine objects and acting on them by name, then you cannot do so reliably (generically).

On the other hand, as all variables have 3 (and up to 5) components (scope, type, role, name, qualification), creating a rule allowing you to reliably compose and decompose the components permits you to act on a group of objects by any individual component.

Example: If you wanted to set the visible property of all Manager qualified fields in a generic loop, you could name your objects reliably:

txt_first_name
txt_first_name__manager
txt_last_name
txt_last_name__manager

Then, you could loop through all your containers controls, parse out the rules based object name, and act on the qualification component (__manager) en mass.

Bottom Line: Rules based object names are far more powerful than on-demand naming conventions.

Your thoughts are welcomed.

Phil
Reply
Michael Ibexsays:
Wednesday, November 24, 2004 at 7:20:48 AM
Thanks for the naming convention info! I've been trying to put my own together, but it just seemed quite a task. Right now, I am doing some research on the validity (just to make sure) and universality of the conventions you offer. I am developing an asp.net application for a bookstore. I come from a strictly-algorithms programming realm, with a little bit of interfacing and file organization (mostly Java and a little of C/C++ and VB6), so naming wasn't a porblem considering the size of porgrams. You're welcome to email me and let me know about what you like :)
M. Ibex
Reply
Santisays:
Saturday, January 1, 2005 at 12:39:26 PM
Hi, I liked your naming conventions section in your page.
Keep up the good work :)
Reply
Irfan Afzalsays:
Monday, January 24, 2005 at 5:06:26 AM
here are conventions which i was finding. there was a helpful stuff for me. thank you very much
Reply
Colin Angus Mackaysays:
Thursday, January 27, 2005 at 8:03:39 PM
I arrived at your site because Marc Clifton is using your coding standards for his Open Source project on WDevs.com http://wdevs.com/Default.aspx?tabid=80 and I liked the look of them and I will be using them for the coding standards of my up-coming open source project.
Reply
Jonathan Evanssays:
Wednesday, February 9, 2005 at 4:41:28 AM
Found using Google. I must say I do slightly disagree with your opinions on Hungarian Notation. I been programming for many years and in many languages. In all of them I have found it useful to "decorate" my variables with a few characters to give a vague idea of the type and scope. So now, in VB.NET, I'll use variables with a name like "sUserID"; this is especially useful in the case where the name gives no real clue as to what type it might be - an ID could easily be a number. However, I agree that it is easy to go too far. I have seen all parameters decorated with "the" in the past; and once heard it seriously suggested that parameters also get decorated with the pass-by type (e.g. v for byval and r for byref). You won't be persuading me to get rid of my m_, g_ or k decorations either. Apart from that though I found your standards useful and will be linking to them from my own in-house standards document.
Reply
Patti Nemethsays:
Thursday, February 17, 2005 at 11:52:39 AM
Pete,
These standards are great. I am on a team and we are in the process of setting up programming and SQL standards.
Thank you!
Reply
Pierre-Paulsays:
Friday, February 25, 2005 at 10:34:01 AM
Awesome, we were looking into Microsoft's website to establish standards in our company but you're site resumes it all in one clean table!!!
Reply
Mike Overlandersays:
Thursday, March 17, 2005 at 9:34:18 PM
Came accross a link at ASNA.com's developer site for .NET naming conventions. Trying to now learn OO programming after 17 yrs on IBM midrange(no easy task). HO scaler too, as well as shop volunteer at TVRM in Chattanooga, TN, currently assisting in the rebuild of SRR E-8 #6914. Like the WM info. Good luck on the layout. Mike.
Reply
Martin Dahlborgsays:
Tuesday, March 22, 2005 at 7:16:19 PM
Thank you for a nice overview of the .NET naming conventions. I enjoy your simple layout and funny web site name. Best, Martin.
Reply
Jeffrey Peggsays:
Thursday, March 31, 2005 at 6:16:24 PM
Very nicely put together list of naming conventions. thank you for putting this up. I am a VB.NET developer from Tulsa Oklahoma doing mostly desktop/winform applications with MSMQ/Indigo communication.
Reply
Andrew Waysays:
Friday, April 15, 2005 at 9:03:30 AM
Love the Common .NET Naming standards. Have been looking for guidance on many things, and MS have given me a heads up on common .NET standards - but really wanted some further guidance on what do to "inside" my classes/procedures. You've put your n#ts on the line and said "just stop using Hungarian"... so I will.

I think I'll keep a little Hungarian for the controls, but will use _ for Private fields and variables.
Reply
Sean Fackrellsays:
Monday, April 18, 2005 at 4:49:28 PM
Great article, especially the history of the demise of the Hungarian convention. I think that good naming conventions are a fine balance between readability, reference, productivity and discipline. Getting the balance right is very difficult and there is no one-size-fits-all. I think that the changes that have come about as a result of VS.NET's IDE and the full use of objects are a good opportunity to get it back on track.

I'm just starting out with .NET coming from a SQL, VB6 and VBA background and will definitely take your article on board. Thanks.
Reply
Rashmisays:
Wednesday, April 20, 2005 at 4:19:27 PM
Thank you for providing the naming conventions and best practices.
I hope that you put some more best practices.

Thanks
Rashmi
Reply
Dan Shanyfeltsays:
Thursday, April 21, 2005 at 12:09:11 PM
I really like the system. I have struggled with finding a good, pretty and consistent nomenclature. My supervisor is leaving, so now I can ditch the bizarre Hungarian that he insisted upon. The only thing I don't see is a rule for private methods. Do you name them like member variables with the preceding underscore to differentiate from the public methods? The only reason I see a need for any prefix is combining overloaded public methods into private methods to reduce repeated code.

So..

public void DoSomething()
{
_DoSomething(0); //Default 0
}

public void DoSomething(int SomeID)
{
DoSomething(SomeID)
}

public void DoSomething(string SomeName)
{
int someID = _SomeLookup(SomeName);
DoSomething(someID);
}

private void _DoSomething(int SomeID)
{
//Actually do something
}

An entry in your guide about private methods would be helpful.

Thanks,
Dan
Reply
Bart Millersays:
Friday, April 22, 2005 at 6:41:54 PM
Good article on HTTPModule. Didn't even know what this was until today. I found your site because someone had linked to the Hungarian Notation info page.
Reply
Tim Watsonsays:
Friday, April 29, 2005 at 10:32:01 AM
My employer has a fabulous framework with loads of good pattern implementations, MVC based web apps and all sorts of goodies. What i fail to understand is why they're sticking religeously to a hideous and convoluted version of hungarian even in .net projects. The entire folder structure uses 5 character prefixes (apprently for security compliance with some ISO standard or another) but i don't see any value in prefixing class or method names with gpint gpyyy and other crap like that. What on earth am i going to do to persuade them that we need to move on from this neanderthal naming convention!?
Reply
Tim Watsonsays:
Friday, April 29, 2005 at 10:32:02 AM
My employer has a fabulous framework with loads of good pattern implementations, MVC based web apps and all sorts of goodies. What i fail to understand is why they're sticking religeously to a hideous and convoluted version of hungarian even in .net projects. The entire folder structure uses 5 character prefixes (apprently for security compliance with some ISO standard or another) but i don't see any value in prefixing class or method names with gpint gpyyy and other crap like that. What on earth am i going to do to persuade them that we need to move on from this neanderthal naming convention!?
Reply
charusays:
Tuesday, May 10, 2005 at 1:55:41 PM
Great website for naming conventions
Reply
Jim MacDiarmidsays:
Thursday, May 26, 2005 at 9:09:10 AM
Thanks for the Coding and Naming convention standards! I've been looking around for this and saw your site mentioned on the ASP.NET advice mailing lists.

Jim
Reply
Marshall Jonessays:
Tuesday, June 7, 2005 at 6:43:50 PM
Hi,

Liked your piece on naming convertions in .NET. Glad to see another who knows the truth about Hungarian.

I'm adopting your ux prefix too. Thanks for the tip.
Reply
Rob Kentsays:
Wednesday, June 8, 2005 at 12:39:36 AM
Thanks. Naming convention for constants?
Reply
Renésays:
Thursday, June 9, 2005 at 6:14:43 AM
I was looking for naming conventions - and what I found was informative, concise and interesting - re the Andale Mono font. This is available for free:
http://sourceforge.net/project/showfiles.php?group_id=34153&release_id=105355

Keep up the good work
Reply
Peter Osuchasays:
Tuesday, June 28, 2005 at 2:37:19 PM
Thanks for the article/summary of .NET naming conventions, Pete. I look forward to starting my work in .NET with appropriately (and correctly!) named variables, methods, classes, etc. - since it took me a few years to realize this when I started with VB4.

Take care.
Peter
Reply
Ravi Thambireddysays:
Wednesday, July 6, 2005 at 3:57:37 PM
Thank you for precise naming standards for .Net development. In one quick glance I know how to name my code artifacts. I appreciate that you have tried to keep the standard as close as possible to Microsoft naming conversions guidelines.

I have suggestion to include components (non visible controls, like tooltip, that you can drop on the forms.) in the naming convensions. You know, these are not really controls but at the same time these are not like your member variables.

Here are my options;
- use ui Prefix like controls
- camel case
- camel case with _ prefix. (Not sure if VS IDE supports this.)

I am really struggling to pick one. Do you have any suggestions?

Do you have any details why plural for only enumerations that represent bitwise flags? I would like plural for all the enumerations or none.

Thank you
Ravi
Reply
akurvaanyadsays:
Monday, July 11, 2005 at 10:07:46 AM
anyadatbasszadmeggeci!
oszt szedjed lefele azt a kepet de gyorsan! biztos valami taho amcsi kocsog vagy, oszt megtalaltad a paintet a kibaszott windowsodon te paraszt. na keressel magyar-paraszt forditot oszt fordulj bele. a veresseguordog bassa meg a gecibemartott villajaval az ilyen furkoid gecimaradekokat. rgszxyzpdqYourHungarianKiller
Reply
jayakumarsays:
Wednesday, July 20, 2005 at 9:50:55 AM
you suggested the usage of hungarian notation for the all the controls in the form
Is there any standards for naming the controls in the visualstudio.net environment
if so pls give me the same

jai
Reply
Itaysays:
Sunday, August 7, 2005 at 9:54:08 AM
I've just read your paper about .Net naming convention,
and I've to admit that it's the best one I've seen yet.
you've clarified and explained all the related issues very nicely
anc clearly and you helped me in making my mind on this part
in my project.
Reply
Billsays:
Sunday, August 21, 2005 at 10:36:29 AM
Searching for articles on C# naming conventions. I found your article very useful,
Thanks.
Reply
Alexsays:
Tuesday, August 23, 2005 at 12:49:46 AM
the naming convention stuff is very helpful. It's easier for me to settle down and be consistent now and defend the way I name things against attack! Thanks!
Reply
Erhhung Yuansays:
Monday, August 29, 2005 at 5:30:56 PM
Thanks for summarizing the naming conventions. I have always been anal about coding conventions in corporate projects -- using Hugarian notations a lot, as well as adding m_ (member), s_ (static), pi_ (parameter input), po_ (parameter output), and even l_ (local), when the IDE's weren't so friendly. I welcome the new conventions, but sometimes when I browse other people's code using CVS web or in Emacs, I can't take advantage of the IDE's mouse-over to tell me what a variable is, so no naming convention is perfect. I've sent you an e-mail directly about a specific naming collision problem, so I hope you can give me a good suggestion.
Reply
Andy Creighsays:
Sunday, September 4, 2005 at 11:41:51 AM
Hi, I'm just starting to use VB.Net and was looking at your naming conventions section - very helpful thanks.
Reply
Joesays:
Wednesday, September 14, 2005 at 1:53:06 PM
Nice info. I've read about the Hungarian notation falling out of favor with .NET, but wondered why. Your page really cleared a lot up, and it makes sense now that I think about it. I'll probably switch to keep from being difficult. No reason to make programming any harder than it is. :)
Reply
Klaus Bjørnestadsays:
Friday, September 16, 2005 at 5:23:49 AM
Hi there! Nice to find good, clean recommendations regarding Naming Conventions/Standards and Best Practices.
Reply
Joseph Touliersays:
Monday, September 19, 2005 at 4:15:20 PM
Thanks for your standards but it would be better if you separate the different explanations in the HTML table. For large cells it's rather difficult to find where a cell starts or ends.
Reply
Kenneth Newmansays:
Thursday, October 6, 2005 at 2:12:19 PM
Great Site...It's refreshing to find a site with content these days.

I was instructed by my visualbasic.net textbook to check your site for reasons why naming conventions have changed.
Reply
Simon Garrattsays:
Tuesday, October 11, 2005 at 10:33:22 AM
I think your standards document is excellent. Thanks for putting it out there.
Reply
Barbara Sue Smithsays:
Saturday, October 22, 2005 at 1:59:01 AM
google. no reply needed this is an assignment for XP Pro class at Napa Valley College. I am to find a six page web site giving step by step instructions for creating the perfect naming convention. Perfect is impossible.
Reply
Jeffery A. Jonessays:
Monday, October 31, 2005 at 8:36:11 PM
Just a note to express my appreciation for posting the .NET Programming Standards and Naming Conventions. As a beginning programmer, this information will save me the time of having to develop a standard of my own. While I have spoken to some who expressed enjoying the opportunity to be creative and develop their own unique way of coding, I find a standard to be beneficial to all who come in contact with the code.
Reply
Bradsays:
Thursday, November 3, 2005 at 1:02:03 PM
I can not thank you enough for writing this article. I was told as a fairly new .net developer to stop using the “Hungarian Notation.” I did ask why but the team leader simply told me that the standard had changed. Since he was in charge I did so immediately and told myself when I move to a new project I would switch back (I didn’t however). Now it is as natural to me as breathing.

I started a new contract about two months ago with several junior developers who are still using “Hungarian Notation.” When one of the QC guys saw my code they sent me the companies programming standards document. I explained that their standards were old and no longer considered “Best Practices”. He did ask why and since I was unable to answer he suggested that I change my code to conform to their standards. So since I still wondered why the standard had changed I went back to my desk and instead of changing my code I started looking for WHY. You have answered the question of why, now I can tell him.

Sincerely grateful
Brad

P.S. do not even get me started with “what was QC doing looking at the code!” That is a whole separate rant for me.
Reply
BrijRaj singhsays:
Tuesday, November 8, 2005 at 1:49:05 AM
These coding conventions are really easy to mug up.
I would love to see more about, conventions while creating the BusinessLogic, And DataAccess Layers.

Thanx Sir,
Reply
Jose Fuentessays:
Wednesday, November 9, 2005 at 2:12:03 PM
I would also add to your .NET Programming Standards and Naming Conventions article that Properties shouldn't have the same name as an existing class.

Such as

Public component Component {

I've seen this so many times, it's driving me nuts, I confront C# developers on this and they see nothing wrong with naming a property the same as a class, they say it makes it easier for them to remember the Class the property is. Convert this to VB and boom you got problems.

Am I nuts?
Reply
hoppysays:
Sunday, November 20, 2005 at 10:19:33 PM
I think it would be helpful to alternate the colors in the rows of the big table on .Net Naming conventions page. It comes out a bit weird with some browsers.
Reply
mnicesays:
Wednesday, November 23, 2005 at 7:00:41 AM
I really like your .NET programming Standards and naming conventions but I just dont see the point on this one small thing: C#/J#/C++ - Keep your curly braces on lines by themselves. Don't put the opening curly brace at the end of the line. If you run across code that does this, simply delete the last curly brace in the code module, and retype it. VS.NET will correct all the other braces for you automatically. The exception is single line statements, such as the accessor "get" in a property that simply returns a variable: get { return _privateVariable ; }
...

I like my code "tighter" and cleaner if opening curly is at the end of the line :)
Reply
Everyonesays:
Wednesday, November 30, 2005 at 5:32:53 AM
A colleague suggested your site when trying to defend some ridiculous coding standards. Turns out some of your suggestions are so stupid that I can't take anything else you have to say seriously.

Prefix user interface controls with ux? You must use Andale Mono, a non-standard font? Give me a break.

Microsoft already provides a wealth of coding guidelines. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcn7/html/vaconVBNamingRules.asp
and many other pages.

It seems you have simply duplicated much of this information and added some of your own oddities. Not very useful in my opinion.
Reply
Petesays:
Wednesday, November 30, 2005 at 5:33:01 AM
In reply to "Everyone". If you had left an email address I could have addressed your concerns personally.

My site far predates the MSDN coding guidelines, and is very consistent with them and the Framework Design Guidelines book.

The "ux" convention is my own. I use it all the time, as do lots of other folks inside and outside my organization. You are free to take it or leave it, as you are any standard. Using it as an excuse to ignore the rest of the conventions seems a bit odd, but you are obviously free to do what you want with your own code.

And yes, I do use Andale Mono and its variants. :) Come Windows Vista I'll use Consolas, which is very similar to Andale Mono, and is targeted towards developers. I'm not sure why that was a point of contention.

Feel free to email me directly at the webmaster address if you wish to discuss any of the points further. -Pete
Reply
Leo LIUsays:
Monday, December 5, 2005 at 9:11:57 PM
My company need a naming standard for ASP.NET and I find this website very useful, thanks for your effort.
Reply
David Cornelsonsays:
Thursday, December 8, 2005 at 2:03:59 PM
Two things that need to be more clearly defined in your standards.

1. How do you name instances of classes in code?

If it's a class level instance, then I use the underscore like any other field. If it's within a method, in C# I simply lowercare the first character. In VB.NET this can cause problems if not outright not compile. I've suggested ClassnameInstance to people, but others prefer objClassname. Microsoft seems to think adding numbers is a valid solution, Classname1.

2. I'm not sure your forms control narrative is complete and "ux" is certainly not a standard that most people would adopt. In my mind, we need to dump the hungarian notation altogether, but most places like the control type somewhere in the name, so I have suggested ControlnameControlType:

Dim CustomerComboBox As ComboBox
Dim Address1Label As Label
Dim FirstNameTextBox as TextBox

One of the reasons you need something to alter the name is that you don't want controls clashing with classes, which you may have mentioned.

Other than that, you're page is an excellent summary of the MSDN information.

Thanks,

David Cornelson
Reply
Quinnsays:
Friday, December 16, 2005 at 11:27:06 AM
This is such a great and informative article about naming convetion in .NET, especially the tidbits and blurb about the Hungarian notation. Thank you very much!
Reply
Derek Blackfordsays:
Monday, December 19, 2005 at 8:57:54 AM
I went looking for programming standards and found your page. This led me to the photos. I really like the black and white F Unit Consist on Bridge photo. I like the copyright "hand writing" -- nice touch. It really makes it look like an old photo.

Thanks
Reply
Sergesays:
Thursday, January 5, 2006 at 11:18:07 AM
I really appreciate your article about .NET naming conventions. Great job.
Reply
Kekakos Eliassays:
Sunday, January 8, 2006 at 11:08:28 AM
I am ready to start a program in VS2005 and I am looking in the internet to see the convention naming of form controls. MS does not say sth specific about this. The opinions are divided in 2: The 1st say yes continue using txtName or mnuFileNew and the others says NO. But what about the ToolStripStatusLabelMessage or FileNewToolStripMenuItem? They are too long (27, 24 chars) to use them like this?
Thanks in advance
Reply
Daniel Leiszensays:
Monday, January 23, 2006 at 7:50:01 AM
Hi!

I found your naming conventions very clear and helpful.
Except the thing, that I wasn't too happy to see the shape of my country cancelled.

Even I don't use Hungarian Notation, and it's an old habbit, for sure. I am hungarian. So please, remove this sign, becouse it's a bit impolite.

Thank you for your appreciation.

Daniel Leiszen
Reply
Spysays:
Wednesday, February 8, 2006 at 3:09:19 AM
Hey, great job with naming conventions, it's really useful.
Reply
Craig Siwysays:
Saturday, February 11, 2006 at 5:47:06 PM
Referred to your website by Visual Basic.NET textbook by Diane Zak, p VB29. It said that your site has an interesting article on why Hungarian notation has fallen out of favor with .NET programmers. I don't know what that means, but I like the wall paper and model railroading. My girlfriend's nephew is a railroad and model railroad fanatic.
Reply
Craig Siwysays:
Saturday, February 11, 2006 at 5:53:04 PM
I guess if I read the text, I would know what Hungarian notation meant.
Reply
Craig Jeffordssays:
Tuesday, February 14, 2006 at 10:10:39 PM
Hi Pete,

Found your site during a VB.NET programming class. Our textbook, "Visual Basic .NET Second Edition", written by Diane Zak, mentions your Hungarian Notation article in the first chapter. Being a relative beginner to VB.NET after supporting legacy systems for the last 10 years and taking a couple VB6 classes, I love the fact that it's standard policy to get away from those old naming conventions. Thanks for a great explanation. I'll check out your best policies when I get more time.

Thanks,

Craig Jeffords
Reply
Doug Meahansays:
Thursday, February 16, 2006 at 3:52:16 PM
A Google search on Naming Conventions brought me to your site.
Thanks for the concise explanation and reference as to why not to use an older naming convention.
Reply
Georgesays:
Saturday, February 18, 2006 at 2:02:32 AM
Hey Pete ... I was reading your history of Hungarian notation. I have always hated it, in general. The period of time during which it became popular, along with misconceived languages like Visual Basic and Java, was the time when (burdened by severe burnout and depression) I decided to get out of software development. I am glad that the industry has overcome / is overcoming some of the worst symptoms of its collective insanity. C# (with ASP.NET) has given me a reason to want to develop software again. Now all I need to do is find an employer who will let me do it for money.
Reply
Marlonsays:
Tuesday, March 14, 2006 at 4:01:39 AM
Great work dude! I liked the little article on Hungarian's origin.
Reply
Sureshsays:
Tuesday, March 14, 2006 at 11:35:30 PM
Thank you very much for the article you have given about the .NET programming standards and naming conversions...
Once again thanks..
Reply
Dansays:
Monday, March 27, 2006 at 1:48:57 PM
This is a great site. Thanks for compiling these standards and everything else on this site.
Reply
manish.nef@gmail.comsays:
Monday, April 3, 2006 at 2:52:45 AM
Hi,
I am a .Net developer working with c#. I want to use standard Naming Conventions
in my Project. So I found this site from google search. I will learn more things
from this site.

Thanking you,
Manish Lad
Reply
Dan Higbeesays:
Monday, April 17, 2006 at 2:33:35 PM
I found this site buy stumbling into it from Google. My search was on naming conventions for .Net.
I'm a programmer in Maryland who also has an interest in railroads. Cool site.
Reply
Andrewsays:
Wednesday, May 10, 2006 at 2:02:26 AM
I have a 'wallpaper rotator' program and was desparately looking for backgrounds for my Spring folder. I love the spring pictures, they are so beautiful! I am thinking of looking for some summer/fall pictures too. :)

I, too, am a developer. Actually, I am developing an operating system (yes, you read that right, an Operating System) in C and I agree that Hungarian notion just doesn't work anymore. I don't have 10000GB of disk space to waste on all these excess letters. I do have one small disagreement, namely, the curly braces thing on if's.

if(something) {
//do something
} else {
//do something else
}

Otherwise I dislike curly braces on the same line.

Thank you for this wonderful resource.

Andrew
Reply
Piyushsays:
Monday, May 22, 2006 at 6:41:23 AM
Hi,

I was reading your article http://www.irritatedvowel.com/Programming/Standards.aspx and agree with you. I tried searching for the Andale Mono font you mentioned and it seems that its available in wiki at http://en.wikipedia.org/wiki/Andale_Mono.

Regards,
Piyush
Reply
Piyushsays:
Wednesday, May 24, 2006 at 3:56:12 AM
Hey Pete,
Just found this - http://www.microsoft.com/downloads/details.aspx?familyid=22E69AE4-7E40-4807-8A86-B3D36FAB68D3&displaylang=en . Looks like microsoft has released a new font for ClearType. You may put this link as an update on your nice article on .NET naming conventions.
Regards,
Piyush
Reply
Jeff Paulsonsays:
Friday, July 7, 2006 at 10:40:53 AM
Your naming conventions for .NET are handy. We don't have a shop standard and probably never will, but since I'm constantly switching languages (VB6, VB.NET, C#, C++, PL/SQL), having guidelines at least helps me to be consistent with myself over time.

If I could ask one favor it would be to make it easier to print the naming conventions page. I haven't tried other browsers, but IE chops off the right-hand side.

Thanks!
Reply
Eduardo Silvasays:
Monday, July 31, 2006 at 9:41:39 AM
About Hungarian or whatever name....

The rason to use universal prefix as fun for a function or cbo for a ui control is the same i want to get a function and just fun cnl+space and there they are.

Simple as that usefull as that

Regards Eduardo
Reply
Dave Pattersonsays:
Monday, August 14, 2006 at 3:03:43 PM
Re: .NET Programming Standards and Naming Conventions

Always a controversial topic, putting forth one's own preferred programming standards and naming conventions is sure-fire way to invite the wrath of others.

Rather than critique the specifics, I'll limit my comments to a few key points:

1) You state up-front that yours represents "the industry-accepted standard naming conventions for J#, C# and VB.NET programs" and point the reader rather generically to Microsoft Help or some other organization.

I counter that this assertion is flatly untrue. You assist me in making my point by noting throughout the remainder of your document where your initial claim for legitimacy is illigitimate. This irritates me, because I read your article precisely because of your claim of legitimacy. Very bad form!

Even if you were to re-justify the article as "My Preferred Coding Standards and Conventions" your article still falls short for one major reason. Most of your choices and "rules", as such, are offered with no justification. Had you provided the reasons behind your choices, the article would have still been interesting, useful and worth reading.

Nice try, I hope you will make another effort some time with greater honesty and clarity.

-Dave Patterson
Reply
David Lincolnsays:
Thursday, August 24, 2006 at 11:54:17 AM
I was looking for opinions on Hungarian notation.... and hit paydirt on your site!
Interesting mix of other topics.....
I have been thinking about hosting a few web sites in my basement. The disclosure of your technical setup is an encouragement!

Thanks,
dwl
Reply
Blessingsays:
Monday, September 18, 2006 at 6:25:12 AM
Hey thanks for the collation of the .net naming standards. i was really finding the MS site a drag to go through
Reply
Barrie Graysays:
Monday, September 18, 2006 at 8:37:22 AM
I will be emailing this link to my clients as I am having a hard time getting them to drop Hungarian notation in .Net and, just like yourself, I never liked it even when it made a kind of sense. I agree with all of your comments and proposals. I may think a tad about the ux prefix for controls, but no doubt will end up with something almost identical, probably "ux". ;)

Thanks for taking the time to assist with the conversion process. --- Barrie.
Reply
Mel Grubbsays:
Monday, September 18, 2006 at 3:05:38 PM
Regarding hungarian notation. I'm waffling, personally. The inclusion of static code analysis in VSTS means one more irritant if I stay with my long-beloved Hungarian notation, and may be the thing that finally gets me to change. My biggest reason for NOT dropping Hungarian has been that there seem to be no strong arguments against Hungarian itself. I've always liked the idea that I could tell a lot about a variable just by glancing at it. Now they say that's unneccesary because you have only to hover your mouse over any variable and Visual Studio will tell you whatever you want to know about it. That's great as long as you happen to OWN Visual Studio, but in my opinion it's a unlikely to be mere coincidence that the people telling us not to use Hungarian anymore just happen to be the same people that sell the tool that makes it unneccesary. This isn't to say I'm a gnu-hugging anti-Microsofty, quite the contrary. My entire livelihood is built around Microsoft technologies, but I still see some places where I'm NOT using VS. For instance, every time I print out some code, or include a snippet in an article all that VS goodness goes right out the window. No amount of mouse-hovering will tell you what kind of variable "user" is when the code is on a website or in a print article. The other major use I have for Hungarian is in the naming of UI controls, which seems to be the industry-standard holdover area. In particular I might have a txtUserName, which has an attached Required Field Validator named "rfvUserName", and possibly some more complex composition rules enforced by a Regular Expression Validator named "revUserName". At least for now that's where I'm drawing the line. I refuse to have hideously complex or arbitrary control names. I'm just not willing to go that far yet.
Reply
William Linsays:
Friday, September 22, 2006 at 9:36:45 AM
Read your excellent summary of coding conventions and wanted to add my $.02 about why I'm a Hungarian notation holdout. In short, it saves me a little amount of time many, many times per day, adding up to a good amount of time saved over the long run. Say I'm coding on a form with, say, 20 controls of mixed types (textboxes, combo boxes, radio buttons, labels, etc.). I want to reference a textbox in my code but can't remember the name. With Hungarian notation, I can just type "txt" and hit Ctrl-Space. Voila - the list of TextBoxes show up and I can choose the right one. Without Hungarian notation, I have to flip back to design mode, click on the textbox to see its name, then flip back and type/paste/autocomplete it. Likewise even with local vars in a function - I want to reference a string, but I forgot the name. Rather than scrolling back up and trying to hunt down where the variable was defined to find the name (particularly irritating in longer functions), I can just type "str" and hit Ctrl-space. Voila - all the strings are listed right there and I can easily choose the right one. This situation comes up a lot for me even when I'm dealing with my own code, to saying nothing of the chase when I'm dealing with someone else's code. Given that Hungarian notation saves me so much time, no one has been able to adequately explain to me why I should abandon it, i.e. why abandoning Hungarian notation saves me more time than having it. Admittedly, I'm not advocating strict, blind adherence to it, as in the case of jagged Arrays of different types or classes that are only used sparingly. But for the common types and controls we reference day in and day out, why not use Hungarian, when it saves me so much effort over time?

Best,
Bill
Reply
Berry Juicesays:
Saturday, September 30, 2006 at 12:29:58 PM
Your naming conventions are great. They are very informative and worth to be standards. Im going to implement all your recommendations to the project I am going to develop. To tell the truth, there are really a lot naming conventions on the web and it gives me a headache on which to choose. I am actually one of those technocrats of hungarian notation and I am going to shift to this standard.

However, the way you explained the usage of "ux" is a bit general in the controls section. It basically teach us on how to use it specifally on user interface and/or the "User eXperience" controls. That being said, it is actually useful to name textboxes, textareas, tables, etc. as such because they pertain on user experience. How should the other tools such as labels, pictureboxes, etc. be named. What I mean is that they are part of the user interface but they do not basically belong to the "user experience". How can I name a name a username label if uxUsername is already present.

ex.
Dim uxUsername As New TextBox()

Dim ??Username As New Label()

What would be the prefix for it.

This is just a very simple issue but it will be very helpful for us obsessive-compulsive novice programmers. I really want to learn more about your naming conventions. Hope you can reply to my question.

Thank you very much.
Berry
Reply
Robertsays:
Tuesday, October 10, 2006 at 3:25:04 PM
When will DotNetNuke get with the program and dump their hungarian notation! I love the product, but their naming conventions just bug the snot out of me!

Thanks for the article.
Reply
Chris Brownsays:
Thursday, October 12, 2006 at 4:15:27 AM
cheers for the VB naming conventions, v. useful
Reply
Jeffrey Bindingasays:
Wednesday, October 25, 2006 at 6:09:51 AM
I found this site very useful, when I was setting the development standards for my company.
Reply
Ian Webstersays:
Wednesday, October 25, 2006 at 11:03:07 PM
Hi There

Thanks for the great article on naming conventions in C#/VB .net.
What i would like to know is what is your take on leaving blank lines between blocks of code or comments
eg
Do you....

//This is my int
int myInt;

Or do you

//This is my Int

int myInt;

and how often do you use regions in your code.

Thanks in advance

Ian Webster
Sydney,Australia
Reply
Kevinsays:
Friday, October 27, 2006 at 4:33:20 PM
Pete,
Just a quick thanks for your page on .NET naming guidelines. As a new convert to .NET and an overworked programmer, I've only had time to "read what I need". I had wondered about continued use of Hungarian and your article has convinced me that not only is Hungarian not necessary, it is counterproductive. Thank you again for taking the time to post this information.
Reply
Darrell Goolsbysays:
Friday, November 17, 2006 at 1:55:48 PM
I was tasked with starting a standards document for our office and this was a great starting point.
Reply
Denzil "Bucky" Bucklesays:
Saturday, December 9, 2006 at 11:50:20 AM
Pete,
Very nice site. I was directed to the article on Hungarian notation and VB.NET in the book by Diane Zak, Programming with Microsoft Visual Basic .NET (2nd Ed.) as a part of my Visual Basic class at the Univ of Phoenix. The railroading part is much more interesting than Visual Basic though! Our town, Sidney, NE, is privileged to have the Union Pacific tracks, constructed originally as the Transcontinental Railroad, and a BNSF track. A lot of coal from Wyoming goes through here on its way to power plants around the nation. One day all of Wyoming may subside, forcing new surveys, grade changes on highways and railroads, and all sorts of fun!
God bless,
Bucky
Reply
Nilesh Kanjisays:
Sunday, December 10, 2006 at 8:30:11 PM
Got the URL to your article on Hungarian notation from Diane Zak's book, VB .Net 2005: Reloaded.

I help teach VB to first year uni students and was planning to sticking to hungarian notation when teaching but your article makes a lot of sense, so we will change to the MS Standard notation instead.
Reply
deansays:
Friday, January 19, 2007 at 6:25:40 AM
Firstly, great list of naming conventions, so thanks for those.

I've got two questions though: if I've got a private variable that's an instance of a datatable what would you name it?

eg:

Private _schoolDataTable As SchoolDataSet.SchoolDataTable

Also say you have a form and you have a text box for pupil name and a label saying pupil name,
currently I'd have lblPupilName and tbPupilName. I quite like your argument for just using uxPupilName, but how would it work in this case?

Thanks again,

Dean.
Reply
Sepiasays:
Friday, January 19, 2007 at 1:59:13 PM
Great information you have here! From running cat5 to .NET coding standards...all in the same place.

Thanks!
Reply
Davidsays:
Friday, January 26, 2007 at 3:54:10 PM
Hi Pete,
Your page on conventions is very informative.
I have a question though.
How do you differentiate between the names of properties that have an enum type and between the name of the enum? Should the property have Camel type?

For instance:

enum Gender
{
Male,
Female
}
Gender _gender;
Gender gender
{
get { return _gender; }
set { _gender = value; }
}
Reply
Margaretsays:
Monday, February 5, 2007 at 8:37:32 AM
Great site on Programming Standards! Had a bunch of useful and readable information. Thanks! MU
Reply
Stevesays:
Wednesday, February 7, 2007 at 4:38:36 PM
Hi there,
Very nice collection of naming conventions and standards! I have followed alot of these and just grown generally with the MS standards. I certainly like the uxControl rather than txt or cbo for exactly the reasons you state.
One thing I struggle with and wonder what your view on this is, and that is TagPrefix on web user controls.
Say we have a web page, and on that page are controls for Langauge, Main Menu, Header, Footer these are all shared between all customers and are our products, so the TagPrefix just use to be "Cadabra". But then we started doing a menu just for customer a. Their name was GoSeeDoNZ.com so we used Gsd as the TagPrefix. Then another customer, Great Travel Advetures, TagPrefix Get (bad name, esp in web space). So we have a mix of tags in the projects cause, the menu we did for customer b, customer b liked, so they did end up sharing the same control. So we generic the control and its now the Cadabra:MenuV2 aand the original is Cadabra:Menu.
So anyway, just wondered what your thoughts were on this, thanks for the great collection of .Net naming conventions.
Cheers,
Steve
Reply
Jon Cottrillsays:
Friday, February 9, 2007 at 10:38:26 AM
Nice site. Good article on naming standards
Reply
Stephanie Giovanninisays:
Tuesday, February 27, 2007 at 1:08:27 PM
I found your web site while searching for C# standards. I sent a link to it to a co-worker who is still stuck on Hungarian notation. Then I ended up reading all sorts of info on your site. Hey, you actually know what PowerBuilder is! Once upon a time, I was a full-time PowerBuilder developer. Then I had a kid, quit, did almost no programming for four years, and then tried to get a job with a resume full of PowerBuilder. I've finally landed in a programming/engineering position and I'm learning C# and .NET 2.0.

I tried my own business, too. It was just a pain. I'd rather have an employer handing me work to do, and then get to go home at the end of the day. No one tried to challenge my domain name (which I still have registered): softwarebyjove.com. It's a pun on my last name, as pronounced in Italian. Not surprisingly, no one else wanted this name.

No reply required... I'm just extremely verbose...
Reply
Russell Haleysays:
Wednesday, March 7, 2007 at 9:34:03 AM
I appreciate the article. I think this is the final straw that will convince me to completely drop Hungarian Notation. Do you have a similar article on SQL syntax standars? I would be curious to see it.

Cheers
Reply
Glen Rhodessays:
Thursday, March 8, 2007 at 11:41:03 AM
You wrote:
"If you are one of these hold-outs, and have good reasons for sticking to Hungarian, I'd love to hear from you. Email me at the webmaster address at irritatedVowel.com, or drop a note in my guestbook".

Just playing devils advocate so don't take this personal...why should I change because you and some snooty MS programmers what to shift directions concerning naming conventions? Who gets to make up the rules...you? Why not some unknown punk like myself?

Glen Rhodes
Sr. Software Engineer
Reply
Scott MacLellansays:
Tuesday, March 13, 2007 at 11:41:36 AM
Fantastic, this was extremely helpful.

I hope I can get my co-workers to come on board with using these coding conventions.
Reply
John Horburtysays:
Tuesday, March 27, 2007 at 11:59:52 AM
Like your coding standards. I adopted these when I first came across your site three years ago. I was using _camelCase for local variables and parameters, as I thought this was a good way to distinguish local fromm global, but can't remember whether I got this from your site, and you've subsequently changed, or whether I made it up. I see you actually use _camelCase for PRIVATE variables, and camelCase for locals and params. Any thoughts on this?
Reply
Mike Ferrellsays:
Wednesday, April 18, 2007 at 8:51:06 AM
Was looking for VB.Net programming conventions and found your site. I still use Hungarian, but I don't use scoping prefixes, and I don't prefix exposed member names. I do include "Enum" in an enum name because I often have a property of that type with a very similar name.

If you get tired of irritated vowel, you could probably substitute an animal or plant ("irritatedpitbull.com"?).
Reply
Rathansays:
Thursday, May 17, 2007 at 1:37:04 AM
What a GREAT site (and a personality) you do have...? I enjoyed every bit of the pages. I came here looking for .Net naming conventions - and have found a lot more. Keep up the good work... and make internet a nice place.
Reply
Mark Hurdsays:
Monday, May 21, 2007 at 8:28:35 PM
I use the Microsoft .NET Library naming convention, except for PascalCase parameters, because they got it wrong there: The basic rule is "nothing public is camelCase", and in VB.NET, and any other language supporting named arguments, parameter names are public.
Reply
Hungarian Notationsays:
Wednesday, June 20, 2007 at 2:21:49 PM
In past years as a contractor I've had the privilege to see many naming conventions. From C through VB through .Net I've seen the norm, the interesting and the down right bizarre.
Though since around '02 most .Net shops (and even those in migration from classic VB) have gleefully dumped hungarian notation, there is one place that sticks in mind.

A wonderfull document of coding guidlines was presented to me on my first or second day there. I think it was written for VB 1, with the platform name changed on occasion (I still have it in fact, it's a very entertaining read).

For now I'll put aside the other absurdities and provide you with the hungarian notion requirements, the most onerous and pointless I've ever seen.
Keep in mind: this is for VB.NET.

First, the norm:
int, lng, sht, bln, str etc etc were of course required, always three characters.
obj for an object goes without saying.

The interesting:
cls for class, dtb for DataTable, dst for DataSet, drw for DataRow, arl for ArrayList, hst for HashTable.
In all a page of nicely annotated abrreviations for dozens of common types (typ by the way).
Woe betide you if you got one wrong.

The down right bizarre:
So far, so classic VB. Then it took a turn for the worse.
99% of all method parameters in .Net are passed by value (i.e. the heap memory address is copied, not the pointer's).
However all by value parms had to be prefixed with bv_ prior to the type. For by ref it would be br_. I.e. bv_intMyIntParm.
Always. No wiggle room.

It didn't stop there.

A function returning a value had to have the type notation prepended.
An interface had to start with itf_I.

Think thats all?

All classes, interfaces, methods, properties and class level fields had to be prepended with the accessor type prior to any other prepended notations.

public = pub_
private = pvt_
friend = fnd_
protected = pro_
protected friend = profnd_

Thus you could have a method that looked like:

Protected Friend Function profnd_dtbGetPersonTable(ByVal bv_intGroupID As Integer, ByRef br_sqeException As SqlException) As DataTable
Try
Dim cntConnection As SqlConnection = clsDataHelper.pub_cntGetConnection(pvt_objMyContext)
Dim cmdCommand As New SqlCommand("GetPersonByGroupID", cntConnection)
Dim dpmGroupID As SqlParameter = cmdCommand.Parameters.Add("GroupID", SqlDbType.Int)
dpmGroupID.Value = bv_intGroupID
Dim dstData As New DataSet
Dim dapAdapter As New SqlDataAdapter(cmdCommand)
dapAdapter.Fill(dstData)
Return dstData.Tables(0)
Catch sqeEx As SqlClient.SqlException
br_sqeException = sqeEx
End Try
End Function

Now imagine an entire enterpise scale application ...
Reply
Manoj Guptasays:
Tuesday, July 24, 2007 at 7:13:34 PM
Content of this site were very usefull.I am writing a document on VB.net coding standards and was not able to find any place for variable naming guidelines.

Thanks for the help,
Manoj Gupta.
Reply
S Smartsays:
Friday, August 10, 2007 at 2:47:58 PM
This site is a big help. I'm a computing and software systems student and the naming standards and conventions have helped me keep all my projects very organized. Thanks!!
Reply
Johnsays:
Friday, September 7, 2007 at 4:07:12 AM
Thanks for putting out the .Net Standards and Naming Conventions.
Reply
Doug Gibbssays:
Friday, September 7, 2007 at 8:13:13 AM
I really appreciate your work on these standards. I've been tasked with formulating our best practices and standards and you have given me a great starting point. Thank you.
Reply
David Msssays:
Wednesday, September 26, 2007 at 9:15:43 AM
I like the new and improved naming conventions for member variables, _, but my problem with your statement is that member variables did start with m_, and it also specified the data type. For example, m_sFirst, told the developer that it was a member string variable.

More importantly, parameter names which now use the camel casing was also suggested to provide a data type. For example, strFirst. Local variables used l_ or simple s. An example is l_sFirst, or sFirst.

Even though Microsoft strongly suggest using the newer naming conventions, they are ones who promoted using the m_ ..... Go Figure.....

Thank you for letting me vent.... Having said, a different approach to naming would be
string _sFirstName; // Member variable names
string sFirstName // Used for local
string strFirstName // Used for parameter

As for objects that are not int, strings or etc, drop the first letter.
Reply
Andreas Eriksson, Swedensays:
Tuesday, October 16, 2007 at 3:32:34 AM
The coding conventions were most helpful - thanks!
Reply
Alicsays:
Thursday, October 25, 2007 at 12:45:44 PM
I use Hungarian notation on projects I am an exclusive developer on. The only reason - when I print out many pages of code to glance through on a plane or in the park, I don't have to flip back and forth between many pages to get a variable's type.
Reply
Stevesays:
Tuesday, November 6, 2007 at 4:36:41 PM
Excellent website - have added to favorites - must return to continue to read your programming articles. Read the naming conventions article - very good.
Reply
khwsays:
Thursday, November 22, 2007 at 10:39:45 AM
Was looking for a coding standard for the team before the start of our very big project. This was a very good place to start, espically the ClearType font stuff. Will mix and match with our in house standards.

Thanks for sharing, very useful.

Cheers :)
Reply
Colin Mierowskysays:
Thursday, December 20, 2007 at 7:05:08 PM
Great piece of work; it matches (almosst) exactly the conventions I have been following for a while. I am in the process of getting a client to adopt these, and the best part is the explanations and rationale for the standards.
Reply
Dassi Bazarsays:
Thursday, January 31, 2008 at 1:02:13 AM
I find the article .NET Programming Standards and Naming Conventions helpfull, will be nice to get a template document for Detailed design (docuemnt to give the programmers)
Reply
ahmedsays:
Monday, February 4, 2008 at 9:59:09 PM
hi,
I came here through google , when I was looking for coding conventions for private members C#, Thanks for your article really, I will go with the straight _ ;). Then I came to your wallpapers section. It is really something you should be proud off , I downloaded a couple.

Thanks:)
Reply
Chrissays:
Wednesday, March 19, 2008 at 8:29:07 AM
I think your artice on naming conventions is superb, and should be widely adopted.

The trouble with common sense is, it't not very common!!
Reply
Wray Smallwoodsays:
Friday, April 25, 2008 at 3:42:46 PM
I still use Hungarian notation but only for one thing, the name of a control, like DropDownList: ddlSystems, Image imgOrangeBall etc. I find it useful to differentiate a control from a variable with a simple notation otherwise you end up doing things like MySystemsControl etc, which pretty much is another convention. Otherwise I pretty much comply with Juval Lowy's IDesign conventions. http://www.idesign.net
Reply
Francisco Magdaleno Csays:
Saturday, May 3, 2008 at 10:50:41 AM
Thank you for you job, a fine job. I didn't know how naming my namesspace, strusturs and so on, I only know about property names, methods and parameters, with fields I was confused (underscore+camel or underscore+PAscal).

You help me a lot :-)
Reply
Ramesh Ranasays:
Friday, September 12, 2008 at 3:01:16 AM
Hi,
I very much appreciate your work on this website. The Standards and Naming Conventions are really best.
Reply
Ayub khansays:
Sunday, October 19, 2008 at 3:12:35 AM
Its very useful for refering the conventions.
Reply
KirkGsays:
Monday, December 22, 2008 at 10:49:28 AM
I have found this helpful. Thanks! I've just started to learn (I mean like this weekend)ASP.NET using C# and I noticed that some of the references I'm working with seem to use different naming conventions. I thought that it would be a lot easier for me if I used the correct naming conventions now when learning rather than later trying to re-learn so I did a web search and found your page. Thanks for the effort you put into it. It really helps a newbie like me.
Reply
Michael Freidgeimsays:
Monday, January 12, 2009 at 10:28:56 PM
http://www.irritatedvowel.com/Programming/Standards.aspx
In rules for .Net "Functions -use Pascal casing" it is worth to note, that the rule is not applicable for JavaScript , where camel casing is recommended for function names.
Reply
Bryansays:
Wednesday, January 14, 2009 at 9:49:16 AM
Google found your .NET Programming Standards and Naming Conventions page for me. I'm going to follow these guidelines. Thanks for putting this page together.
Reply
Steven T Abellsays:
Wednesday, February 4, 2009 at 4:20:04 PM
I'm a Hungarian Holdout.

There are, as you know, many dialects. Many of them result in the troubles you describe. Others are helpful. It is a matter of, as my dad used to say, keeping your pants on when designing your dialect. At www.brising.com/hungarian.html, you'll find links to two dialects: one for C/C++, and a similar one for Java. I'm working in C# right now, thinking about a specific dialect for it, haven't published it yet. The essence of the design of these dialects is that prefix *elements* can only be single characters. If you can't say it in a single character, then don't say it in the prefix. Composing prefixes together according to clear rules of order eliminates the mayhem. I don't have to "mouse over" my variables to know what they are. I know where they came from, whether or not I can assign to them, whether or not they are an array, and their value category in no more than four letters, usually less. I can sit down and read code without looking stuff up. You can't.

As for your example of a "variable that contained a long pointer to an array of arrays of long pointers to some particular structure", try pvvpsGronk, where Gronk is the name of the struct. I can validate my dereferences by looking at the name. You can't. I can read this in somebody else's code and have some hope of understanding how to use it and the cost to use it right then and there. You can't. I actually write code like what you describe, and trying to do it correctly in a reasonable amount of time is something I don't want to even *try* without a good Hungarian.

BTW I'll point out that "_variable" is just the Hungarian idea trying to hide behind not being a letter.

I don't want to come across as hostile: I've been through the wars and I'm tired of them. I've seen what a good dialect can do for a body of code, especially in large projects. I've seen what a bad dialect can do to any body of code. I think the current trendy revulsion of the Hungarian idea is a result of bad dialects that try to achieve everything and end up being a working horror. I hope people can get over that and get back to using a technique that has material payoffs in several dimensions.

BTW2 this might show up as a duplicate posting: I got a server error the first time.
Reply
See Crispsays:
Thursday, March 5, 2009 at 8:26:52 PM
Hi,

Nice page about C# naming conventions.

Although your prefixing of all controls on Forms with ux is the only bit which doesn't seem logical.
A control on a form doesn't necessarily have anything to do with 'user experience'. For example non-visible controls with which the user has no interaction whatsoever.
So after switching from ui to ux, maybe it is now time for you to switch to the prefix fc for "form control".

Bye.
Reply
Shannonsays:
Sunday, March 15, 2009 at 9:02:24 PM
I just read your note on NOT using Hungarian naming/notation and in the instance that you are speaking of it makes sense. However, often I get pages and pages of code (C#, VB .Net, etc) from which I must develop a quote and a statement of work. This is never given in a computer file format but on paper. Try to decipher the meaning of the variable Result with no prefix. I had one program that used this single word over 100 times but not always as the same type (some were integers, some double, some string, and some array). I had to go back sometimes pages to make sure that the variable was of the correct type. Placing a simple int, str, dbl, arry would have made my job easier. This multi use of a single "word" was the problem causing the code to abort with unhandled exceptions. One coder picked up an integer Result and tried to assign it to an array of string type. Another thing is the tbl prefix. Both Oracle and Teradata recommend that tbl or vw be included someplace in the name (usually at the end). If you review the tables, views, and stored procedures in Microsoft's database AdventureWorks you will see that the views and the stored procedures all have prefixes.

The way I look at this is I was a Beta tester for the very first release of Windows for a PC. You could open 7 windows by the code but computers (PC) could only handle 2 because of memory constraints (at best you could open a word processor and sidebar - a scheduling program of the early 80's.) That code written in C was so entangled and had so many badly named variables along with a multitude of GoTo spaghetti loops that it was hard to document where the error (unhandled of course) occurred. Thus I am very leery of any standards developed by Microsoft.

Last but not least I have had to recode programs that used such variable names as: Cat, Dog, grbgtrck (garbage truck) to mean result, Grand Total (that was the garbage truck), and net revenue. That one was bad but I fear with these random naming guidelines where the same variable name can be reused with no identifier (as long as it isn’t in the same class) will cause me far more trouble than my addition of Hungarian notation. At least that way if you (another coder) doesn’t like it and you’re reengineering you can change it.
Reply
Jonathan Harleysays:
Tuesday, March 24, 2009 at 6:07:16 PM
I like everything except the fallback on control names on forms (uxName, etc.) Using the various refactoring tools for renaming eliminates the issue of finding them.

I also tend to prefer camelCasing private methods. That way, I can see in my method calls if I'm exposing something that I shouln't be..

Good work - Jon
Reply
Heraldsays:
Tuesday, April 28, 2009 at 2:05:06 PM
I have found http://www.irritatedvowel.com/Programming/Standards.aspx very userful. Thank you.
Reply
Alireza Haghshenassays:
Thursday, May 28, 2009 at 3:47:51 AM
Wow, thanks for the consistent naming convention and, more importantly, the reasoning behind each one. We were using a similar convention in our company, but in a project, the project manager was specified by the customer, and he's very strict on the old fashioned methods. I decided to do a search and find out which one is really better, and here's your article.

Thanks a lot
Reply
Harald-René Flaschsays:
Tuesday, June 9, 2009 at 4:13:29 PM
Comment for http://www.irritatedvowel.com/Programming/Standards.aspx

I absolutely agree!! Thank you for taking the time to put the important standards to one single page!

(BTW: our "software architect and god of all developers" had some strange ideas we're suffering now (e.g. tabs to spaces - I really hate it!)

I'll print your page Standards.aspx to a big sheet of paper and I'll highlight some thinks our god has botched ;-)))

--hfr
Reply
David Gretleinsays:
Friday, June 26, 2009 at 11:56:32 PM
Greetings -

I appreciate your opinions and recommendations on the user of .NET Programming Standards and Naming Conventions. I cut my programming teeth on C a very long time ago for embedded use (motor controllers, devices, sensors, etc.) ... remember the 4-step Lattice C compiler?

I have worked over the years with the various compilers, IDEs you described in this article such as VB4, 5, and 6 ... over the past couple of years with .NET (ASP, VB, C#). It has been a bit of a challenge to say the least.

Your sidebar on database naming conventions, however, has sparked me to sign your guestbook. And heck, you asked for comments (;^) ... While you say that when you work in SQL Server you already know what the object is ... agreed, but. When you are working with the data access layer or business logic layers in applications, wouldn't you agree that it is useful to distinguish between views and tables? And, as I learned on a project I am working on that Microsoft attempts to look-up a stored proc. if it is named "sp_" as it is the convention for built-in stored procedures.

This project we received from a third-party vendor, they used keywords for naming their tables - User, Order, Return, Group, to name a few and the name of the database is, well, Connect !

With respect to naming conventions within code, I will have to say that if one is reading a hard-copy (or digital copy in a text editor and not the IDE), it is difficult to hover to learn the data type.

Lastly, I am curious to learn of your position on leveraging the line wrap for code that extends well beyond the edge of the viewing area. It is rather frustrating to have to scroll to the right to see the code. So, I try to use the wrap feature (and ask my colleagues to do the same) in whatever code (C#/VB/ASP.NET) so that I can read the whole thing and it is somewhat expected that one will have to scroll downward.

Great article and very much appreciated.

Sincerely,
David Gretlein
Senior Systems Analyst (Electronics Engineer by education)
San Diego, CA
Reply
Brian Hallsays:
Tuesday, July 21, 2009 at 7:44:25 PM
Found your site during a Google search for C# naming conventions. I am an aspiring, albeit late-blooming, developer (32 years old) who is very interested in the C# language for developing an application add-in for the software I use in my day to day work (Autodesk Inventor). No response is asked for here, just thought I'd drop a line in your guest book giving kudos to the site (accolades - not the delicious snack bar). :)
Reply
Jaysays:
Friday, July 24, 2009 at 2:01:23 AM
Excellent! We are referring your article for standardization in our current project
http://www.irritatedvowel.com/Programming/Standards.aspx
Reply
Ethan Watrussays:
Tuesday, September 1, 2009 at 4:45:39 PM
Thank you your site makes far better sense of the standards then the text book from school :)
Reply
Tom Andersensays:
Thursday, October 22, 2009 at 4:16:46 PM
Just wanted to drop you a quick note letting you know I found your read informative. I had the question about naming private members in VB. I come from a c# background and initially didn't want to use the _ for my VB private members. Your stands read put me more at ease. We had just adopted a local standards doc here and I will need to let the team know that the use of _ for private members would be acceptable for VB.NET.

Thanks for the time you spend making the community better:

Tom
Reply
Stephen Lareausays:
Friday, October 23, 2009 at 12:31:40 PM
Great site. My team is currently setting standards to use going forward. I bookmarked your site some time ago and thought, Ah yes, I remember a good post on this very subject. Let me share it. And so thank you. This will surely help steer our team in the right direction.
Reply
Robertsays:
Wednesday, October 28, 2009 at 6:24:50 AM
regarding ".NET Programming Standards and Naming Conventions"

about the programming fonts... I highly recommend the Dina Programming Font (http://www.donationcoder.com/Software/Jibz/Dina/index.html)

- It's a bitmap font which means it will look as clean as it can get. No font-smoothing necessary to screw things up. IMO Consolas and all others I tried look terrible even with clear type.

- It supports bold and italic characters natively, so you can have syntax highlighting make letters bold/italic without messing up the layout. IIRC this is the only monospace font I found, that can do that.

- Characters like l, I o, O, 0 can be easily distinguished.

Well... it has really everything a programming font needs...
Reply
Mark Chimessays:
Tuesday, December 22, 2009 at 2:25:48 AM
Hello Pete,

Love the article on naming conventions!

There is one point that I consider supports the use of Hungarian notation - legacy code.

I find maintaining legacy code, and let face it all code become legacy code sooner or later, is easier if the previous developer has used Hungarian notation.

Often, the code needs to be modified to resolve a new issue that has arisen from a change in business rules; new technology that behaves differently; or even a long standing issue that no one can ignore any longer. This means there is pressure on the developer to get those changes made ASAP, in code that he/she is unfamiliar with.

I know that the IDE can be helpful with tool tips about type, etc, but often you just want to scan the code to find the right place to make that small change, and tracking a variable of a particular type through unfamiliar territory is that much easier if you know which one of many you are after.

I agree that the need for Hungarian has been reduced with the improvement in programming languages, IDEs, etc, but for my job, those little three-letter prefixes make my job just that bit less demanding.

Cheers,
Mark Chimes
Reply
Vegas Guysays:
Monday, December 28, 2009 at 9:25:40 PM
Pete,
I wanted to say thanks for the info on your site. I am a Senior Software Enginner for a large Gaming company in Las Vegas Nevada. I was searching for .NET standards in google when i came upon your site. I wanted to say thanks for the info and I wish that the MSDN site were as easy to find information on as your site is.

You do not need to add this to your guestbook, I just wanted to say thanks for the time that you invested in this site, it is very cool and easy to find information!!!

Thanks Again,
Vegas Guy

P.S. I also used to do some CNC programming on some Mills and Lathes (Fun stuff from my younger days - pre wife and kids)
Reply
Mark Hayssays:
Wednesday, February 24, 2010 at 8:16:34 PM
Dear Pete:

Thanks for the thoughtful and thorough summary of naming standards. I shared a copy with our dev team, as a good place to start for our naming convention.

We are part of a not-for-profit healthcare company, dedicated to improving care for the underserved across the nation and worldwide.

Thanks!

Mark Hays
Reply
Paul D Carpentersays:
Thursday, March 25, 2010 at 4:47:02 PM
Naming convensions.

I know you are stating the defacto standard rather than creating one, but I wish that exceptions would be named starting with "Exception". When writting an exception handler, I always have to go an look up the list of possible exceptions rather than have intellisense give me the list to choose from.
Reply
KenDogsays:
Tuesday, March 30, 2010 at 10:33:26 AM
That is a good idea, if you never print the code out. I don't think my finger has intellisence built in to allow one to distinguish where the variable name came from. For those of us who have to fix the code left behind by those who do not prefix the task can be a fundamentally challanging one. I do like some of the extreme examples you have used to go against prefix notation on variable names. I can only tell that there has been no code review of the aformentioned bad prefix practice. Microsoft, at first did not use prefix notation, and now, they want to go back to no prefix notation odd really, but then, that is Microsoft.
Reply
BennTechsays:
Monday, April 12, 2010 at 10:10:45 PM
As KenDog points out, if you're using anything without IntelliSense, like basic text editors, programmer's editors, simple IDEs, or just plain old paper, then reading code becomes far more difficult without Hungarian notation. Even a simple code snippet becomes indeterminate unless it explicitly includes the definition of every variable used.

Personally, I'm in between the hold-outs and Microsoft flip-flops. I agree the notation gets unwieldy if you go overboard like the comical examples, and long ago I laughed at the absurdities of trying to notate everything. However, I always have and will continue to notate base types, like integers, booleans, and strings, which usually can be notated with a single letter. "bFoo" is far more informative than "foo" when you're outside of Microsoft's IDE, and even in the IDE you don't need IntelliSense to know it's a simple boolean. If that makes it difficult to collaborate with me, then I'm pretty sure you're not the caliber of programmer with whom I want to collaborate anyway. ;-)

I think the whole reason Microsoft is dropping Hungarian notation is self-interest. The lack of Hungarian notion forces developers to use Visual Studio for its IntelliSense feature to keep from wasting an inordinate amount of time just figuring out what types variables are.
Reply
MikeHorsesays:
Friday, April 16, 2010 at 12:04:45 PM
I read this article in hopes that I find find some solid rationale for moving from Hungarian to the more naked approach recommended by Microsoft etc. I remain unconvinced.

Anyone who is a solid coder and not lazy can manage whatever changes might be needed in naming conventions when a type changes. That's routine and easy if you have any skill with your toolkit. So I do not see that as a factor.

I think the two earlier comments are right on. It's one thing to be coding and have intellisense offering up it's support. But scanning a page of code, either that you wrote a year ago, or someone else did...wow without some kind of type support embedded in the text, you've completely escalated the amount of mental computation and interpretation incurred. Even if you're in the vs IDE, and you can glean the type by hovering over the variable name...how you gonna keep track of all that in your head after you've looked up 20 of them?

Honestly, I know there is sense in following the pack, and the technology lead (msft), but this is one instance where I think it's foolish. It would be interesting to hear Pete respond to these comments; and interesting that all comments are not in favor of the new line. Well, it wouldn't be too interesting if Pete just replied 'You're all wrong!", but you get the idea.

Note that for this comment I followed the naming convention used by KenDog and BennTech; a name followed by a ref to something one is presumably fond of.
Reply
Petesays:
Friday, April 16, 2010 at 1:19:45 PM
Hi All

I ported this page over from my old site. I had a lot of comments there both for and against, and a fair number of emails. If I can import them, I will, but I suspect not.

I haven't commented on this yet as I'm trying to wrap up my book, and want to make sure I give you all a well-thought reply.

Good info here. While I may not agree with some of the arguments, I appreciate you all taking the time to make them.

Pete
Reply
Ian Smithsays:
Friday, April 16, 2010 at 1:45:52 PM
As I recall, the original explanation for relegating the long popular Hungarian notation prefix to "nasty code smell" was that there were so many types in the .NET system that it was impossible to come up with 3 or 4 character prefixes for all of them. This always struck me as rather ridiculous as their main use had been for UI controls (of which there had never been THAT many) and their usage does make code more readable when looking at listings.

The irony is that the "new" standard for Silverlight XAML pushes hard for butting the same information that Hungarian Notation prefix used to help with into a much longer form at the end of the name of the control. eg "ContinueButton", "AgeTextBox" etc I believe that the main justification as to why this is a "good" thing (while Hungarian Notation Prefix is a "bad" thing) was tied to style sheets which target certain controls. Whatever, it seems an arbitrary decision to have gone this way rather than with Hungarian Notation.

All that being said, it's amazing how much heat this subject generates when really there are far more important things to get upset about.
Reply
Reed Copsey, Jr.says:
Friday, April 16, 2010 at 2:00:47 PM
I personally think that Hungarian Notation is more harmful than helpful. If you are working on the code, there is no reason not to be using a good IDE, in which case, the type is always immediately discoverable.

If your looking at code in print or on the web, and not interacting with it, then properly named variables is more useful than an instant understanding of the type.

Any properly formatted, refactored code, when reading the code (not editing), should be very obvious. The actual types have very little impact on the algorithm involved. The goal of reading code is understanding the basic conceptual framework in place, and the algorithm in question. In this context, the type of a specific variable is meaningless.

By using Hungarian Notation, you're just adding "noise" about the type, which is not really useful for understandability of the algorithm itself.
Reply
Petesays:
Friday, April 16, 2010 at 2:19:55 PM
Hi All

I just imported the old comments related to this article from my original site. Unfortunately, since I replied to them personally via email, you only see one side of the discussion. Never-the-less, I think it adds a bit more to the picture.

Pete
Reply
Brian Hendersonsays:
Friday, April 16, 2010 at 3:38:25 PM

Using Hungarian Notation to embed ‘type’ into parameters is bad practice, but appending a construct to provide additional context can be useful in some domains. (eg. …Attribute, or ux…)

A must read: http://c2.com/cgi/wiki?HungarianNotation

Note the _param and m_param was introduced into .NET naming to support VB.NET's (v1.0) lack of distinction between upper & lower case in relationship to exposing properties. Since .NET is a cross language platform, other languages picked up on the convention. Latter VB.NET versions handle this case-clashing at the compiler level.

.NET has become a large ecosystem crossing many domains. Any naming conventions used must take the context & domain they are used into consideration. eg. If programing in F#, Ruby, or Python, one will adjust naming styles, same goes when following an alternative methodology eg. BDD (behavior driven development). There will never be one unified naming convention & coding standard.

We as professionals we must consider the most practical and consistent way to define the characters used to tell the story we write in code. Consistency and predictability are important for our audience to follow and understand the threads that make the code work.

B+
Reply
Sivaprakasamsays:
Tuesday, May 4, 2010 at 3:19:08 AM
SuperbNotation

~siva,
TN, INDIA
Reply
JcRamossays:
Friday, May 14, 2010 at 9:01:19 AM
I am impressed at the quality and detail of the information provided...even if I don’t agree 100%. The heavy reliance on the IDE capabilities is a path leading to trouble. Development tools are not all equal and each shop has its own preferred flavor, mostly dictated by the organization's financial status. Calling a thru and tried practice bad just because it can be misused by misguided personnel is not valid. While the MS IDE does wonders and I love it, I will never recommend moving completely away from Hungarian Notation. I use a simplified form of it for base types it cannot exceed six characters; it just makes reading code easier. Being able to read some lines of code and discern what is doing quickly is what separates the good ones from the ticket punchers, yet even with super skills a piece of code without proper naming conventions is a tough pill to swallow and downright confusing.
The beauty of being a programmer is that there are a million ways to write a piece of code. At the same time this is the most frustrating. The hardest thing about being a programmer is consistency.
Again thanks for the great info. I will integrate some of your recommendations, with some of my own, into my shop’s standards.

JC
Reply
Dansays:
Sunday, May 16, 2010 at 10:59:59 PM
@Jc - I think in reality, anyone programming in the .Net world is likely using a highly capable IDE such as Visual Studio. I'm sure there are exceptions, but they aren't common place.

That said, I do agree about the usage of hungarian notation in some areas. In addition to the exceptions in the naming conventions in the framework itself (suffixing derived EventArgs, Exceptions, etc with those names), I usually will apply it to UI elements. NameTextBox and NameLabel are useful at a glance to know what APIs are available on those objects. And when you refactor these items in a way that change their type, odds are (unless you are editing xaml directly), you are doing so from the designer in a way that removes the object and replaces it with the new one.

To sort of reiterate Brian and Reed, the inclusion of type "noise" to a variable can lead to some hard to follow code. Suppose you have a variable intSomeNumber, and in the course of refactoring, you need to change this to a long type. You end up having to change the variable name, and any other variables related to that (say in another class or in a parameter) to keep the code readable.

I admit that I inject scope into my personal naming conventions (I prefix variables with a, the, arg to represent local, member and parameters... Yeah, I know that goes against the underscore convention for member variables, but I think it's easier to read and outside of the reflective debugger, you can't see the member variables anyway). Sometimes it's nice to know (at the very least) that a variable was a parameter so that you avoid creating a side effect function by mistakenly modifying a property in a class instance passed in as a parameter.
Reply
MeSampathsays:
Wednesday, May 19, 2010 at 2:00:54 AM
Very good information. Thank you for sharing.
Reply
Flintsays:
Wednesday, May 19, 2010 at 7:26:17 AM
Hungarian is definitely not perfect for this, but it works.

this is why I use it... have read all of the above and no where do I find a solid argument against it, At All :)
Reply
Dmansays:
Thursday, May 20, 2010 at 8:40:48 AM
Just came across this and was amazed at not only the information but the relevancy of the article after 6+ years. Thanks for the info again!
Reply
Shustersays:
Tuesday, June 8, 2010 at 11:08:07 AM
About the Controls on Forms

On the one hand, I agree in recommending to only name controls which need to be named. but I also recommend
to name all controls just becouse it gives you the manage control of all over the existing elements. And when you believe that your are loosing that control. Maybe you should reconsider the desing of the form.

On the other hand, I no agree to name the controls as shortly as possible. The strong reason is tha we wanto to know more than just the name and type of the control, we also want to know its location on the form. So I recommend not to sparing in naming the controls. Always is a well form to do it. You have the choosing oportunity on how to do it.

ei. <asp:TextBox ID="txtBx_BeginDate_FindInvoice" ...> // Maybe FindInvoice is tab control
<asp:TextBox ID="txtBx_BeginDate_CreateInvoice" ...>

Greetings!!
Reply
Shustersays:
Tuesday, June 8, 2010 at 11:09:15 AM
About the Controls on Forms

On the one hand, I agree in recommending to only name controls which need to be named. but I also recommend
to name all controls just becouse it gives you the manage control of all over the existing elements. And when you believe that your are loosing that control. Maybe you should reconsider the desing of the form.

On the other hand, I no agree to name the controls as shortly as possible. The strong reason is tha we wanto to know more than just the name and type of the control, we also want to know its location on the form. So I recommend not to sparing in naming the controls. Always is a well form to do it. You have the choosing oportunity on how to do it.

ei. asp:TextBox ID="txtBx_BeginDate_FindInvoice" ...> // Maybe FindInvoice is tab control
asp:TextBox ID="txtBx_BeginDate_CreateInvoice" ...>

Greetings!!
Reply
Surajsays:
Sunday, July 4, 2010 at 3:46:55 AM
hey thanks dude.. your mentioned standards and guidelines are really good ..
Reply
Michael Kellersays:
Saturday, July 17, 2010 at 11:06:09 AM
I have looked for a complete and in-depth coverage of .NET naming conventions for a long time. I have found lots but none of them had the Why that yours include. Most said they were based on Microsoft but had really rolled their own conventions. So it pretty much got down to, "this is what we do in our shop."

You have provided a valuable service here to Microsoft developers. Thanks

--Mike
Reply
Eugenesays:
Monday, September 13, 2010 at 1:08:54 AM
I really like the idea of the member variables starting with "_", and I use this all the time.

One issue I've always had though, is how to distinguish properties from constructor parameters.

For example if I have the following in my class...

private _recordId as Integer

...

Public Property RedordId() as Integer
...

Public Sub New(redordId as Integer)
_recordId = recordId
...

This works fine. However it can easily come unstuck if I change the parameter name, but forget to change the assignment in the constructor body. For example...

Public Sub New(myRedordId as Integer)
_recordId = recordId
...

This wont actually generate any errors in VB, because recordId in the assignment would simply start referring to the property instead of the parameter. In effect the variable would be assigned to itself.

To me this seems a fairly serious limitation of the standard naming convention. Ideally I would think that there should never be any potential for ambiguity.

One possible variation of the standard that I have tried, is using a double underscore for parameters (i.e. __recordId.

Because the parameters, private member variables and public properties all use unique names, if I change the parameter name, and forget to change it in the constructor body, then the compiler would correctly throw an error.

This works, but it possibly isn't very elegant. I've also never actually seen this used anywhere else.

Does anyone have any other thoughts on the best way to handle this?

Eugene
Reply
Dave Brownsays:
Sunday, September 26, 2010 at 6:32:47 PM
Hi Pete

I confess I am one of the diehard holdouts.

My argument for Hungarian Notation is that it is EnglishSense and not French or LatinSense.

When reading code that is written using Hungarian Notation (or as I call it plain old English), the reader does not really read the leading characters like int, col, obj. These are disregarded automatically by the brain, but they are and aid to the adjective of the noun).

I confess to being English and therefore I like to see the "adjective" before the "noun". Thus a vehicle of color red is in fact a "red car" and not a "car" "red" like the French would have us believe. Or a _vehicleRed.

The move to the c, c++ world notation is very Latin. . . and I still don't understand why the Microsoft Visual Studio IDE when creating form controls like a text box still defaults the naming convention to an expanded Hungarian Notation like "TextBox1".

Your article though was very useful in addressing in highlighting the preference for French style naming conventions over normal English usage of adjective and noun. Well done!

Kind regards
Dave Brown
Reply
Fernando Fsays:
Tuesday, October 5, 2010 at 10:26:56 AM
Increible 2010 disccussion yet? easy for human beens (natural language) or easy for compilers.?
I like to see the "adjective" before the "noun" for some things but for others (SQL, LINQ) inverse es better?
French, Latin, Romance vs English? where is the undertanding problem?.
Uohhh.
Reply
Pradeepsays:
Monday, October 11, 2010 at 3:33:56 AM
Hi,

Is there any naming convention for a page in a web application?

For example, I have a page called applicationdownload.aspx
Is this the right way to name the page, or do you have any better suggestion, like ApplicationDownload.aspx?

Thanks,
Pradeep.
Reply
Website reviewssays:
Thursday, December 16, 2010 at 9:22:46 AM
Thanks for this sharing. Its so helpful. keep it up
Reply
Amirsays:
Wednesday, December 29, 2010 at 5:54:01 PM
So, what about the last paragraph of the MSDN guideline at here:
http://msdn.microsoft.com/en-us/library/ta31s3bc(v=vs.71).aspx

It is: "Do not apply a prefix to field names or static field names".

What is this?

Is it better to use "this." or "_". Also "this." will be useful to call the methods or properties, then it will be distinguish the "static" and "instance" methods.

Am I right?
Reply
Anil Mujagicsays:
Monday, February 21, 2011 at 5:29:49 PM
Hi Pete,

It seams comments on this post will never cease :)

There is one thing about coding conventions and guidelines I couldn't find an official opinion on. I hope I'll get one from you :)

It's a code order in the C# class file I'm talking about. Are there any official recommendations and what do you think is the best practice regarding that.

I usually put class level variables and auto-implemented properties first, constructors follow, properties after them, then methods and event handlers.

What is your recommendation?

Anil
Reply
Caseysays:
Monday, March 14, 2011 at 2:08:45 PM
I am a fairly new programmer, I learned VB6 in 2003. It taught me to use Hungarian prefixes. I really liked them until one project I had to change all my lists into text boxes! Yes I re-named the variables. They work well in intellisense, and also after I was reading a book that had c code and vb code next to each other I realised that the hungarian prefixes were training me to put the variable type before the name. But you are right, they are silly, and cumbersome. I didn't know they were using such complex prefixes, mine were simple, str int lbl lst , I didn't like using cbo for combobox, or cmd for command button, I changed that to lst for any kind of list, and btn for any kind of mouse clicakable item. But I"m saying goodbye to all that.
I'm still trying to learn naming conventions for classes, so I looked at this article. One writer said to drop the m in private property variables (containers or whatever, forgot the term) but I didn't realise you could keep the _underline, so I was struggling with naming the parameters. Now I don't have to deal with that.
Thanks.
Reply
Deansays:
Tuesday, March 29, 2011 at 6:36:00 AM
Really useful article. Thanks Pete.
Reply
Tobysays:
Wednesday, April 13, 2011 at 9:27:44 AM
Thank you very much for this article. You given a concise and well reasoned standard.
I've been undecided about hungarian-style notation in scripting languages for some time. This has given me clear reasons to drop it once and for all.
Reply
Richsays:
Wednesday, April 13, 2011 at 4:34:30 PM
I guess I'm an old school holdout, even though I didn't know I was old school. I learned VB.NET in 2003, and have developed a number of programs along the way in my position as the only IT person in the place, so I was not exposed to anything different than what I had been taught. Now I'm going through C# 2010 Step by Step by John Sharp, and when I got to the section on WPF I was shocked that the text box was named "FirstName" and not "txtFirstName", so I did a search on c# naming conventions and found this page. Thank you - it is quite enlightening. I'll have to give this a try to see how I like it. Thanks.
Reply
Steve Naidamastsays:
Wednesday, April 20, 2011 at 11:18:02 AM
Though I completely understand all of the article's reasons for not using Hungarian Notation based on what is being done in corporate IT currently, I have been using a basic form of this notation since the early 1990s and still use it in all of my .NET development.

However, my understanding of this article does not mean I accept all of the premises promoted.

Charles Simonyi did not develop Hungarian Notation for Microsoft; at least not based on the very early documents I read on this subject. He had actually developed it for mainframe COBOL development and it was far more complex in nature than what is described here.

The reasons given for not using it are based on what has become rather sloppy development practices in recent years. Want to change something, no problem... There is little or no documentation within or outside of the source-code in most installations. Thus, changing a text-box that would hold alphanumeric data can now be changed to an integer with current practices without any regard for the data-type of the original data. In fact, with the C# "var" keyword we no longer even have to worry about data-typing since this little gem has completely thrown us back to the days of interpreted BASIC which was denigrated for years because of its lack of strong typing mechanisms.

Mainframe disciplines are long gone from a field where technical personnel had far more basic information memorized than current developers, where most of what is known is useless detail about what is more efficient coding practices or how an object is boxed or unboxed. Thus, in the mainframe world developers were expected to know what they were looking at when analyzing source-code. As a result Hungarian Notation was used to help developers interpret not just variable declarations but procedural paragraphs and what sub-paragraphs were related to a calling one.

Today, many developers are hooked on "gadget technology" including the wizards and intellisense of modern IDEs. Most don't know how to research the knowledge they require by going through books and other such research materials and studies done on the concentration powers of younger developers corroborate this. As a result, many could not develop an application without such aids without straining to look something up every time they write a line of code.

Is all this better. Not really since developers are doing the same things today I did on the mainframes, just differently and with a lot more power at their fingertips. However power is not a replacement for knowledge, including the use of Hungarian Notation which requires specificity and not generality where the world of ambiguity has superseded that of precision...
Reply
George Williamssays:
Wednesday, May 4, 2011 at 10:08:06 PM
I've been coding for over 20 years now, (remember GW Basic?), and I started using a hungarian type notation for my variables right from the start, to tell me , by inspection, what data type they were. When VB came along, it just seemed so natural to continue, and use hungarian on my controls as well. Now I code in C#, as well as C++ (when I'm backed into a corner) I still use it, because it would be harder to change, and it is so plainly helpful. Incidentally, I heartily agree with Steve Naidamast when he says that the 'var' keyword has thrown us back to intepreted basic. I have ALWAYS used strong typing, even when VB allowed (even encouraged in some cases) the untyped variable. The unlucky junior coders that allow me to scrutinise their work, leave my office with their ears ringing with my taunts. My final repost is always "write it so other people can understand it", and however outdated it may be, hungarian notation, applied judiciously and with a lot of common sense does just that. Steve, maybe we should get together and tell our war stories sometime.
Reply
Majidsays:
Monday, May 23, 2011 at 3:35:17 AM
hi, pete
Thanks, Really useful article.
Reply
HellspawnDevelopersays:
Friday, June 3, 2011 at 9:39:52 PM
Great article...easy to see why its popular.

I would just like to add that i disagree a little with the recommendation that acroynms within classes, namespaces and assemblies should be camel case.

Imagine you're working for a company called: Best Entertainment Technology

You're writing a poker application called Poker101

You want all your namespaces to have the company acroynm in it.

According to your recommendations, a class called Bet, which when referenced via full qualification would look like:

Bet.Poker101.Bet

Hence i believe that acroynms in namespaces, assemblies and classes should be all CAPS in order to distinguish them as an acroynm:

BET.Poker101.Bet
Reply
Nigel Majorsays:
Tuesday, June 7, 2011 at 5:29:00 PM
NIce article, thanks. One thing though, While I agree with not bothering to rename non-referenced objects in XAML, I do frequently use a simple prefix in windows interfaces (forms or WPF): I find it useful to distinguish between display elements that are potentially editable by the user, and those which could issue commands. So I use an "e" and a "c" prefix to clarify this intent. Not a huge effort, but it does help communicate the intent: whether we use a combo-box, a slider or radio buttons to select an option from several is just a matter of style, especially in WPF/Silverlight, where providing a different interface is now so easy so we can expect the UI to evolve anyway ... but when a coworker needs to use my code they are quickly aware of what is editable, what is a command source, and what is neither.

Thanks for exposing the rationale behind all this!

Regards, Nigel.
Reply
Alexsays:
Friday, January 20, 2012 at 9:45:45 PM
Does anyone have a full list of VB object names?
Thanks!
Alex
Reply
Petesays:
Friday, January 20, 2012 at 10:53:21 PM
@Alex

Why would you need that? Maybe check the object browser or MSDN?

Pete
Reply
Shanesays:
Wednesday, February 1, 2012 at 12:41:35 AM
Thank you for a great article!

I am in the process of updating some software that I created 4 years ago, and has since been maintained by two others. Over the years you can see major differences between my naming conventions and those of the other programmers, and I needed to set some type of standards going forward.
Reply
Human Centred Design says:
Thursday, February 2, 2012 at 10:09:06 AM
Lots of good links here. I use a bit of php when developing my sites but I would like to learn more. Will you post more?
Reply
niushasays:
Tuesday, April 10, 2012 at 12:28:43 AM
thanks for your site.
Reply
prateeksays:
Wednesday, May 23, 2012 at 8:45:49 AM
hi guys, I m somebody which is very new at this ,can you guys suggest me something which makes my learning easier for .net
Reply
Derek Johnsonsays:
Thursday, March 14, 2013 at 5:51:00 PM
I have a good reason to continue using Hungarian notaion: I am an old man who is tired of learning new names for the same old things! I have been programming for Windows since v1.0 and over the years, Microsoft, among others, has driven me near crazy!!! With all the advancements of technology, it is a shame no one has developed more tried and true software conventions that have survived (maybe MVC qualifies, if you research.)

My opinion:
If hardware engineers changed conventions as fast as software engineers, we would still be using punched cards and magnetic tape. I suppose it keeps a lot of people in jobs...

Some old favorites:
"If builders built buildings the way programmers wote programs, then the first woodpecker that came along would destroy civilization." - Gerald Weinberg

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rick Cook

"Patterns and practices are certainly good things, but they should always be framed in the context of a problem you're solving for the users. Don't succumb to the dark side." - Jeff Atwood
http://www.codinghorror.com/blog/2004/12/it-came-from-planet-architecture.html
Reply
Mona Shahsays:
Monday, August 19, 2013 at 11:53:46 AM
Very nice set of conventions!!
Reply
Brucesays:
Friday, November 15, 2013 at 12:51:15 PM
Interesting article, although I disagree Hungarian or some way of describing the type is useless.

I did C programming under linux/windows and now C# under windows, as well as maintaining legacy things written in a range of things (C, Delphi, Fortran, some assembly). There's code which is 30 years old which is in business use today, and I have to run the IDEs under emulation to maintain that code.

Yet, it works, is used, and someone has to periodically make changes to it, and it's a hell of a lot easier when the variable names are descriptive, give indication of type (preferably, give indication of scope). You can bet programming languages and tools are going to change and change again, and your new code today is someone's legacy code ten days after, and even the naming conventions will naturally change (and you'll have to change them yourself if you change employers, most likely).

My guiding principle is: It's better to be verbose and save (yourself, or someone else) a lot of time later, then save a few keystrokes now. That means data types, too. I personally have the habit of describing complex structures with a description afterwards (eg. a two-dimensional pointer array I'll usually call something like blabla_blabla_ptr_table).

I do skimp on the verbosity for things which are of local scope to a function or method. It also helps (esp. in older languages) with not getting mixed up what's local and what's not - if the name is short, then it's some sort of temporary variable which is reusable, if it's long and descriptive, it's not.

Also, It doesn't make any sense whatsoever to be a religious zealot regarding standards of variable naming.

A lot of the time you most likely won't get to pick them yourself, so no reason to fuss over it. If you're working under someone else (I never have, so I use my own notation, personally), you have to use whatever notation they picked. If you're maintaining legacy code, it's honestly best practice to use the notation the original programmers used, otherwise the whole code will become a mess (imagine, someone might have to maintain it after you).

Currently I'm developing a business app in C# using a style / design philosophy which would probably drive a "purist" seething with rage (I'm a C programmer at heart, and it shows), but it's readable, easy to navigate, and will get the job done in the time I have to do it (which is not very long). During your career you'll see styles, design philosophies, conventions and whatnot change many times, it's not really something to get worked up about.
Reply
Adalinmipsays:
Saturday, January 2, 2016 at 5:22:04 PM
[B][CENTER]STAR WARS: EPISODE VII - THE FORCE AWAKENS (2015) 2D/3D AC3 HDRip e

[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/og0sqtdc35z8diz1mdjijtzv8.jpg[/img][/url]

[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/c6s6xnuw732vgd0g9isezfsdk.jpg[/img][/url]

[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/gjnvwc5v3fr78x5ojq62womdp.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/eh82od8xqtjtn6mtmiqac6jt1.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/ibk32l97zhqiy9sut1cvr6hxt.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/emulrvus6mkhkh7ryegw1gn43.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/6y0sie53pmn06jmgqwnecslyf.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/uvj1xejt2wdot7fkrmnqsmzbq.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/fej6f1jmz23j6b1u04yug34ob.jpg[/img][/url]
[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/nexk3uf8lpkagdkc9l3slwm0g.jpg[/img][/url]

After the Battle of Endor, The Empire picks up what's left and forms The First Order and continues their mission to wipe out the Rebel Alliance, now known as The Resistance...

Studio: Walt Disney Pictures, Lucasfilm
Director: J.J. Abrams
Screenwriters: J.J. Abrams, Lawrence Kasdan
Starring: Harrison Ford, Andy Serkis, Anthony Daniels, Kenny Baker, Peter Mayhew, Carrie Fisher, Mark Hamill, Oscar Isaac, Max von Sydow, Adam Driver, Domhnall Gleeson, Gwendoline Christie, John Boyega, Daisy Ridley, Lupita Nyong'o, Crystal Clarke, Pip Anderson, Christina Chong, Miltos Yerolemou
Genre: Action, Sci-Fi, Adventure

Video: HDRip DivX 5 720x544 23.98fps
Audio: MPEG Audio Layer 3 44100Hz stereo 256Kbps
Total Time: 126:27 min
File Size: 1.5 Gb

[URL=http://vip-file-xxx.org/?page_id=224]DOWNLOAD[/URL]

[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/f98gxp9243vyurg3ul79lygeb.jpg[/img][/url]

[url=http://fotoxxx.eu/][img]http://fotoxxx.eu/img/2015-12/13/6lfqj4i14rprusaufxvxu6id5.jpg[/img][/url][/B][/CENTER]