Before I explain where and how to name the different elements of your application, let's briefly look at the different standards employed today.
Hungarian Notation
adopted this famous—or infamous, depending on your point of view—naming system based on ideas from Simonyi's doctoral thesis, "Meta-Programming: A Software Production Method."
Hungarian notation specifies that a prefix be added to each variable to indicate its type. However, not every type was given a standard prefix. In addition, as other languages were introduced and new types created, new prefixes had to be created. This is why even if you go into a shop that employs Hungarian notation, you might see some prefixes you're not accustomed to seeing. (By the way, the term "Hungarian notation" comes from the fact that the prefixes make the variables look as if they are written in a language other than English; plus, Mr. Simonyi is from Hungary.)
Perhaps the most important publication that encouraged the use of Hungarian notation was the first book read by almost every Windows and OS/2 developer: Charles Petzold's Programming Windows (Microsoft Press), which used a dialect of Hungarian notation throughout its demo applications. In addition, Microsoft employed the notation in its own development. When MFC was released, a bunch of new prefixes specific to C++ development were released with its source code, thereby guaranteeing the continued use of Hungarian notation.
So why not simply continue using Hungarian notation? Because Hungarian notation is useful in situations where it's beneficial to know the type, or scope, of a variable being used. However, as you'll see in more detail in the next chapter, all types in C# are objects and based on the .NET System.Object class. Therefore, all variables have a basic set of functionality and behavioral characteristics. For this reason, the need for Hungarian notation is lessened in the .NET environment.
NOTE
For the curious, or for those suffering from insomnia, the original paper that presented Hungarian notation can be found at http://msdn.microsoft.com/library/techart/hunganotat.htm.
Pascal Casing and Camel Casing
Although it's been impossible to pin down the C# team on a "hard" standard, it is obvious from their writings that they're following the notation set forth by fellow Microsoft employee Rob Caron, who suggests using a mixture of Pascal and camel casing when naming variables. In his paper "Coding Techniques and Programming Practices,"
available at MSDN (http://msdn.microsoft.com/library/techart/cfr.htm), he suggests using Pascal casing on method names where the first character is capitalized and camel casing on variable names. Accordingly, I've chosen to use the same naming convention in this book's demo applications. However, because C# contains more elements than just methods and variables, in the following sections I've listed the different elements and the naming conventions that I've seen Microsoft use internally and that I've chosen to use as well.
NOTE
For more information on this topic, you can refer to the .NET Framework guidelines included in the .NET Framework SDK documentation under .NET Framework Developer Specifications\.NET Framework Design Guidelines\Naming Guidelines.
Namespaces
Use your company or product name, and employ mixed casing with an initial capital letter—for example, Microsoft. If
you're in the business of selling component software, create a top-level namespace that is the same as your company name and then for each product, create a nested namespace with its embedded types, which will prevent name collision with other products. An example of this can be found in the .NET Framework SDK: Microsoft.Win32. This strategy might result in more long-winded names, but remember that the users of your code need only specify the using directive to save typing. If your company is called Trey Research, and you sell two products—a grid and a database—name your namespaces TreyResearch.Grid and TreyResearch.Database.
Classes
Because objects are supposed to be living, breathing entities that have abilities, name classes by using nouns that describe the class's problem domain. In cases where the class is more generic (that is, less specific to the problem domain) than that—for example, a type that represents an SQL string—use Pascal casing.
Methods
Use Pascal casing on all methods. Methods are meant to act—they carry out work. Therefore, let the names of your methods depict what they do. Examples of this are PrintInvoice and OpenDatabase.
In the case of methods that will be used in Boolean expressions, prefix the method with a verb that indicates what the method will do. For example, if you have a method that will return a Boolean value based on whether a workstation is locked, name the method something like IsWorkStationLocked. That way, if the method is used in an if statement, its meaning will be much clearer, as shown here:
if (IsWorkStationLocked) ...
Method Arguments
Use Pascal casing on all arguments. Give meaningful names to arguments so that when IntelliSense is used, the user can see immediately what each argument is used for.
Interfaces
Use Pascal casing on all interfaces. It's common to prefix interface names with a capital "I"—for example, IComparable. (This is the only Hungarian notation"like convention that I know of in C#.)
Many developers use the same rules when naming interfaces as they do when naming classes. However, there's a fundamental philosophical difference between the two. Classes represent an encapsulation of data and the functions that work on that data. Interfaces, on the other hand, represent behavior. By implementing an interface, you're saying that a class can exhibit that behavior. Therefore, a common technique is naming interfaces with adjectives. For
example, an interface that declares methods for serializing data might be called ISerializable to easily denote the capability being taken on by the implementing class.
Class Members
This is probably the stickiest issue with regards to C# developers. Those of us coming over from C++ and MFC are accustomed to prefixing member names with m_. However, I would recommend using camel casing, in which the first letter is not capitalized. That way if you have a method that takes as an argument something called Foo, you can differentiate it from the internal representation of that variable by creating the internal member named foo.
It's redundant to prefix a member name with the class name. Take, for example, a class name of Author. Instead of
3 4
Summary
Writing, compiling, and executing a program written in C# is an important first step in the exploration of the language.
Although in general it doesn't matter what program you use to edit your C# source files, there are benefits to using more powerful editors and environments designed for C# development. Knowing the options and switches of the C#
compiler will allow you to take control of how MSIL code is generated by the compiler. You can explore that code by using tools such as ILDASM, included with the Microsoft .NET Framework SDK.
The structure of C# programs provides for a number of features designed to make programs safer, easier to write, and less bug-prone. Included in this feature set are namespaces and the using directive. Finally, naming conventions, which include specific casing conventions, can make programs more readable and easier to maintain.