Common casing styles include: PascalCase In a compound name (such as "input stream" or "base type"), capitalize the first letter of each word, then eliminate the space. Thus, "input stream" becomes "InputStream" and "base type" becomes "BaseType". camelCase In a compound name, the first letter of each word is capitalized, except for the first word, which is left lowercase. This produces, for example, "baseType" and "inputStream."  If the first word is an acronym, it is usually lowercase, as in "xmlParser."  This style is typical in Java. ALLCAPS This style is generally only applied to symbolic constants. All letters of the word are uppercased (as if typing with the caps-lock key down), and spaces are eliminated, for example "BASETYPE" or "INPUTSTREAM". Identifier names should be descriptive, concise, and meaningful to someone reading your code.  In general, Microsoft recommends: Anything declared as "public" or "protected" should be PascalCase, including class names, properties, methods, and events. Internal names may vary subject to project standards.  The Microsoft convention appears to be PascalCase for methods, events and properties, and camelCase for fields. Symbolic constants (the value of pi, and so forth) should be shown in ALLCAPS. IMPORTANT NOTE Since some .NET languages such as VB.NET are not case-sensitive, do not differentiate between two C# methods using only case.  To do so would make your code non-CLS compliant. Interface names should always be prefixed with I, following in COM tradition. The second letter of the interface is also capitalized, as in IComparable.  Note that interface names are usually adjectives (Comparable, Disposable) rather than nouns.  Other than the I for interfaces, do not use any sort of prefixes on names. This is what namespaces (see below) are for. Attributes should always end in the Attribute suffix. If you follow this convention, the C# compiler can use shorthand naming rules (allowing you to leave off the Attribute portion of the name when using the attribute). Events should be suffixed with EventHandler; event argument types should be suffixed with EventArgs. Frequently, events are prefixed with an On, indicating the event is fired "on button clicks" or "on window closing"; this is not entirely consistent, however. Exceptions should always be suffixed with Exception. Enums should use PascalCase, both for the typename and the values within the enumerated type. Fields should be named relative to what they store. Microsoft specifically recommends against using Hungarian notation, even the MFC m_ style; however, this style shows up in a few places inside the FCL. Use what feels right to you and your peers, but be consistent. Namespaces The general pattern to follow when naming namespaces is: CompanyName.TechnologyName Some examples of well-formed namespaces are: Microsoft.Office Corel.OfficePerfect OReilly.CSharpInANutshell Microsoft recommends using PascalCase for namespaces.  You must separate logical components with periods (for example, Microsoft.Office.PowerPoint).  It is occasionally appropriate to use another casing convention for namespaces (for example NeXT.WebObjects, OReilly.Network and ee.cummings). Plural namespace names are recommended where appropriate — for example, use System.Collections, not System.Collection. Exceptions to this rule are brand names and abbreviations — for example, use System.IO not System.IOs. Never reuse names across namespace and class names — for example, the System.Debug namespace should never have a class named Debug within it (this is scoped to the namespace itself; it is perfectly acceptable to have a class called Debug in the System.IO namespace). As more companies code for the .NET platform, "company-level" namespaces may clash. Java sought to avoid this problem by advising companies to use their reverse-DNS name ("oreilly.com" produces "com.oreilly" top-level namespace names). But name collisions have not been a problem, and many companies simply use the "center" part of their DNS name (for instance "oreilly" instead of "oreilly.com"). There is no reason to believe this namespace convention won't work well in .NET.