System.IO.Path

When Not to Use Hungarian Notation

Hungarian prefixes should be used only for variables, parameters of private members, and (optionally) constants. Hungarian prefixes should not be used for procedure, property, or event names, as they reduce the readability of such items. In addition, prefixes should not be used for parameters of public properties and methods because the class might be accessed by languages that support a different set of data types, in which case the prefixes won't make any sense. For example, when creating a property to hold a value for Length, you'd use a statement such as this:

Public Property Length() As Integer 

If you used a prefix of int, object members wouldn't look right in the IntelliSense drop-down lists. Not only would they not look right, the list would be sorted by type and not by name, which would make finding members rather tedious. Even if you knew the member's type, you'd have to type at least four characters just to find the item in the list. And your code would look odd as well. Consider this example:

objMyObject.intLength = 5 

Note

Because you shouldn't use prefixes on parameters of public members, you might choose not to prefix the parameters of private members as well, and that's OK as long as you stay consistent.

 

In the past, I preferred to use prefixes for classes and forms. However, doing so in .NET will cause your namespace definitions to have prefixes (for example, Tigerpaw.fclsCustomer). In addition, forms are now classes, so it's best not to use prefixes for classes. However, some method of designation is needed to show when a class is a form class vs. a traditional class. Consider the following statement:

Dim frmEmployee As New Employee() 

What, exactly, is Employee? You could deduce that it is a form class because the variable has the prefix frm. However, this is based on an assumption that the variable itself is named correctly. If the Employee form class were named EmployeeForm, this is what the statement would look like:

Dim frmEmployee As New EmployeeForm() 

Notice that all ambiguity has been removed. Think of the word Form as a qualifier, much like First, Last, Min, and Max. You're not actually denoting data type that would be done with a prefix but rather you're qualifying the variable.

In Visual Basic .NET, changing the name of a form doesn't change its file name. Even if you choose not to use the Form suffix for your form names, I encourage you to use the suffix when naming form class files. In previous editions of Visual Basic, each object type (form, class, module, and so on) had an extension that specifically denoted its type. In Visual Basic .NET, all object files share the extension Visual Basic; there simply is no way to look at a file and know what type of object the file represents. By using the Form suffix on your form class file names, you'll make managing large projects easier.

Note

Essentially, to mirror the .NET Framework, Hungarian notation needs to be completely internal to the object. All your public interface elements should be camel-cased with the first letter of each word in the name capitalized (for example, CustomerForm and DialPhoneNumber) and should not use any Hungarian prefixes. By keeping your public elements Hungarian-free, your application will follow the .NET model from an exterior point of view, but you'll be able to continue to enjoy the benefits of Hungarian notation throughout the "interior" of your projects.