Lesson 44 - Naming Conventions for Identifiers

Get GitHub Code

This lesson discusses the topic of naming conventions for common coding elements, such as, public classes, methods and properties, private fields, locally scoped variables, and so on. There are naming conventions that are established by the developer community at large. Then there are project-specific conventions agreed upon within the organization that you work in. Naming conventions are put in place to make it easier to discern meaning, and intent, in code.

Step 1: Understanding PascalCasing vs camelCasing

Capitalization schemes are a common convention used to made code easier to read and follow. Often times, capitalization helps to distinguish the item that is being named. The two main capitalization schemes are “PascalCasing,” where each word in the identifier is capitalized, and “camelCasing” where the first word is lower case followed by capitalization for subsequent words:

In general, everything that is public will be PascalCase while everything that is private will be camelCase. Take, for instance, this block of code:

1. The public class name Hero is PascalCase.

2. The public property Name is PascalCase.

3. The private backing field _name is camelCase

4. Thee private heroHelperMethod() method is camelCase.

5. The public AttackPattern() method is PascalCase.

Step 2: Using Underscores for Backing Fields

Notice how the backing field is prefixed with a single underscore. This is a general convention programmers adhere to when referring to backing fields. One of the reasons for doing so is you can quickly see, via Intellisense, that the member is a field.

Notice, too, the use of an underscore inside the constructor method for the Hero class. This is a naming convention used by programmers to help distinguish the private variables inside a class constructor from the input parameters displayed to the user. When creating methods, you want IntelliSense to display something easily understandable when showing what input parameters the method takes in. In this case, the Hero takes in a name and hitPoints:

What this does is:

1. Creates the input parameter (name)
2. Creates a local variable (_name)
3. Sets _name equal to the input parameter "name"

You, the programmer, can then know which variable you are modifying, all while displaying easily understandable instructions to the end user:

Variables that are locally scoped – that is to say, initially declared within the body of a method – are generally supposed to be camelCase. In this example, the hero, battle and damageInflictedOnMonster objects/variables are only “alive” within the context of this local Page_Load() method, so they are set to lower-case/camelCase accordingly:

Step 3: Where Server Control Property References Come From

You may have noticed that we have been referencing Server Controls in the Default class through class-level instances of these Controls. However, you may be wondering where exactly that instance was defined. As you can see the Default class is declared as a partial class which means that this is only a partial representation of it and another part of it is somewhere else. If you were to right-click on a Server Control via its instance, such as the resultLabel, you can select “Go To Definition” to see the other part of this class definition:

You can see that the instance is indeed a field within the broader class definition for the Default class. You will also see that it has a protected accessibility modifier, meaning it is private to this class and inheriting classes, which is why camelCase is used.as Also, on the topic of Server Controls, notice how we have been including the Control name within the identifier to help communicate what it is an instance of. This is similar to a practice called “Hungarian Notation”:

Step 4: Older Conventions Like ‘Hungarian Notation’

While not common within the .NET development community, you may see some code that subscribes to the “Hungarian Notation” naming convention. The hallmark of this convention is the inclusion of the variables type – usually trimmed down to three characters or less – prefixed directly to the variable name. Here is the meaning behind the Hungarian Notation used below:

• The ‘i’ in iCOunter refers to type int.

• The ‘str’ in strFirstName refers to type string.

• The ‘btn’ in btnOk refers to the Server Control type.

• The ‘C’ in CPerson refers to this as being a class.

Tip:

Hungarian Notation may seem like a good idea, but is generally considered to be an outdated way of representing coding elements. This convention lost favor for a host of reasons including the fact that the intended meaning tends to be forgotten in a broader system and is difficult to remember and enforce.

When using a development environment as sophisticated as Visual Studio, it becomes quite redundant to include type and scope information directly within the variable name itself. You have a variety of tools that will volunteer this information to you with as little as moving the cursor over the variable name: