. NET Programming Standards and Naming Conventions

Original article: http://www.irritatedvowel.com/Programming/Standards.aspx

. NET Programming Standards and Naming ConventionsCommon. NET Naming Conventions

These are the industry-accepted standard naming conventions for J #, C # and VB. NET programs. for additional information, please see the MSDN help documentation and FX Cop. 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 failed t in visual controls. these naming standards shocould find their way into all of your. NET development, including ASP. NET Web applications and. NET 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. 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 consistant in their internal code in. 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. 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 stronugly 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.

If you find these to be helpful, be sure to drop me a note in my guestbook.

 

Type	Standard/Convention	Example
Namespaces	Standard Based Upon Microsoft. NET Library Standards Pascal Case, no underscores. use CompanyName. policyname 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 shoshould 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. 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 particle 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 shoshould not have the same name as the namespace in which they reside. any acronyms of three or more letters shoshould 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. 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 handle T in the event handlers. try to avoid abbreviations. extends programmers have a nasty habit of overly abbreviating everything. this shoshould 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 versions 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 versions 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 versions 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 wowould 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 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 should t for the underscore. As far as m _ goes, it is really just about aesthetics. I (and other others) find m _ uugly, 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 cocould 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 versions ages that will support it. If I want my class to be fully CLS-compliant, I cocould 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 your respects, especially for intelliisense 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 wocould 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, IOnlyName 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 defix for yourself.   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 intelliisense ). "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 intelliisense 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 intelliisense. 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. 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 shoshould a consumer need to know if you have an enum, or (perhaps because they are strings) a class exposing public con Stants? 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. 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 ;-).

Please don't copy and paste these conventions on your own site. feel free instead to link directly to this page. that way you get the ability to automatically get updates when I make them, as well as get that warm fuzzy you get by not copying someone else's work. schools and accredited educational institutions can paste these conventions on their own sites if and only if they include a direct link to this page an attribution for the source of the information from "Pete Brown's irritatedVowel.com ". thank you for respecting my wishes on this.

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 2005 +.