Naming Conventions


ASP.NET Developer's JumpStart
By Paul D. Sheriff, Ken Getz
Table of Contents
Appendix A.  Programming Standards

While you're developing new code, you'll spend a large portion of your time naming things. You'll need to propose names for variables, procedures, and more. The following sections propose standards for providing names, thus allowing for consistency in your code.

Naming Variables

Although it's subject of much debate, we believe you should adopt a strict and consistent naming convention for variables in your applications. Because variables describe the behavior of your code, it's useful to be able to glance at a variable and determine its type (and perhaps its use) just given its name. We've adopted a commonly used convention, starting variables with a two- or three-letter prefix that indicates the data type of the variable.


We've found one programming convention that consistently leads to confusion the habit of using single-letter variable names. We can't suggest strongly enough that you avoid the temptation. The only place we'll allow this (and it's still a matter of contention) is in simple integer values used for looping counters.

Taking into account our own coding styles, we suggest you consider adopting these same rules when naming variables:

  • Avoid one-letter variables.

  • Make all variable names mixed case. That is, each word or abbreviation within the variable name should be capitalized. This technique is often referred to as camel case, because you end up with "humps" in your names, like this: intTotalValue.

  • Do not use the underscore character in a variable name. (There's no point if you use mixed-case names.)

  • Preface each variable name with a two- or three-letter prefix indicating the type of data it contains.

  • Abbreviate names in variables only when absolutely necessary.

Hungarian Notation

Hungarian notation is a variable-naming scheme created by a Microsoft developer of Hungarian nationality (hence, the name). Originally developed for C language programmers, it has now been successfully applied to many other development languages. The use of Hungarian notation in a program will give developers useful information about a variable simply by inspecting the name of the variable. A variable that has been named using the Hungarian notation scheme indicates the variable's scope (Global, Member or Local), what data type it contains (Integer, Long, and so on), and, of course, the purpose of the variable.

Although originally created for C developers, Hungarian notation is just as useful in Visual Basic applications, and we endorse its use. Although we don't adhere to it "religiously," you will find that all the variables used throughout this book do include data type information, and we suggest that you follow at least this part of the naming convention.

Hungarian notation can be useful within your code, but there are places where it can be confusing or misleading. You should not use Hungarian notation when naming any of the following variables:

  • Public property names

  • Public method names

  • Public event names

  • Parameters to procedures

  • Properties in a structure

  • Enumerations

Basically, we suggest that you don't use Hungarian naming on any name that's publicly viewable in any IntelliSense list.

Data Type Prefixes

Table A.2 lists the standard variable data types in Visual Basic, along with suggested prefixes for these data types.

Table A.2. Data Type Prefixes
Data Type Prefix Example
Boolean bool or bln boolIsValid or blnIsValid
Byte byt bytValue
Char chr chrLetter
Date dt dtStart
Decimal dec decValue
Double dbl dblValue
Integer int intLoop
Long lng lngValue
Object o oValue
Short srt srtValue
Single sng sngValue
String str strName

Scope Prefixes

A variable's scope defines the locations within your application where a particular variable may be inspected or modified. For example, a local variable is one declared within a procedure. This variable may only be read or modified while code is executing within the particular procedure. A member variable, on the other hand, may be used from within any method within the same class. Global or public variables (whose use you should consider restricting, for maintainability reasons) may be referenced from any procedure or function within the same project. We suggest using the single-letter prefixes shown in Table A.3.

Table A.3. Variable Scope Prefixes
Prefix Description
g Global or Public scope throughout the entire project.
m Member variable within a class definition. This variable has scope throughout the whole class.

Local variables should not have a prefix. This will distinguish them as being local and not having a scope outside of the current procedure:

 Public gintLoop As Integer  ' Public variable Private mstrName As String  ' Member variable Dim boolOpen As Boolean ' Local variable 


You can declare member variables (variables that exist within a class, outside a procedure) using the Dim keyword or the more explicit Public, Private, Friend, or Protected keyword. We strongly suggest you never use Dim to declare a member variable always use the explicit modifiers so that it's never a guess as to how a variable is exposed to other classes.

Naming Controls and Menus

Just as you use prefixes indicating the type of variables, we suggest using a prefix to indicate the type of controls you use on your user interface. That way, it's easy to tell from within your code exactly what type of control you're working with. Table A.4 lists the Web Form controls and the suggested prefixes for those controls. Table A.5 suggests prefixes for use with Windows Form controls.

Table A.4. Web Form Control Prefixes
Control Prefix
Label lbl
TextBox txt
Button btn
LinkButton lnk
ImageButton img
HyperLink hyp
DropDownList ddl
ListBox lst
DataGrid grd
DataList dlst
Repeater rep
CheckBox chk
CheckBoxList cbl
RadioButtonList rbl
RadioButton rdo
Image img
Panel pnl
PlaceHolder plc
Calendar cal
AdRotator ad
Table tbl
RequiredFieldValidator reqv
CompareValidator cmpv
RangeValidator rngv
RegularExpressionValidator rexpv
CustomValidator custv
ValidationSummary vsum
Xml xml
Literal lit
CrystalReportViewer crv

Table A.5. Prefixes to Use with WinForm Controls
Control Prefix
Label lbl
LinkLabel lnk
Button btn
TextBox txt
MainMenu mnu
Checkbox chk
RadioButton rdo
GroupBox grp
PictureBox pic
Panel pnl
DataGrid grd
ListBox lst
CheckedListBox clst
ComboBox cbo
ListView lvw
TreeView tvw
TabControl tab
DataTimePicker dtp
MonthCalendar cal
HScrollBar hscr
VScrollBar vscr
Timer tim
Splitter spl
DomainUpDown dup
NumericUpDown nup
TrackBar trk
ProgressBar prg
RichTextBox rtxt
ImageList ilst
HelpProvider hlp
ToolTip tip
ContextMenu cmnu
ToolBar tbar
StatusBar sbar
NotifyIcon nic
OpenFileDialog ofd
SaveFileDialog sfd
FontDialog fd
ColorDialog cd
PrintDialog pd
PrintPreviewDialog ppd
PrintPreviewControl ppc
ErrorProvider errp
PrintDocument pdoc
PageSetupDialog psd
CrystalReportViewer crv

If you take care to name your controls with these common prefixes, you'll be able to identify the type of a control reference in your code without having to refer back to the page or form.

Windows Forms Menu Naming Conventions

When creating Windows applications, you'll often use menus on your forms. Just like custom controls, all the various menus you create should also be prefixed appropriately. The prefix mnu should be used on all menus. This prefix should be followed by the caption of the menu. For each pull-down menu under the main menu item, use the first letter of the top-level menu. Table A.6 lists some standard menu items and how you might name them.

Table A.6. Menu File Naming Conventions
Menus Name
File mnuFile
File, New mnuFNew
File, Open mnuFOpen
Edit mnuEdit
Edit, Copy mnuECopy
Edit, Paste mnuEPaste

When you use this convention, all members of a particular menu group are listed next to each other in the object drop-down list boxes (in the Code window and Property window). In addition, the menu control names clearly document the menu items to which they are attached.

Naming Conventions for Other Controls

For new controls not listed in the tables, try to come up with a unique three-character prefix. Note, however, that it is more important to be clear than to stick to three characters.

For derivative controls, such as an enhanced list box, extend the prefixes listed earlier so that there is no confusion over which control is really being used. A lowercase abbreviation for the manufacturer could be added to the prefix, for example.

Naming ADO.NET Objects

Although thousands of objects are available as part of the .NET Framework (and we wouldn't even consider providing naming standards for more than a few of the framework classes), you're likely to use ADO.NET as part of your applications, and we'd like to suggest some naming standards for the common ADO.NET objects. Table A.7 lists the prefixes we use throughout this book.

Table A.7. Prefixes for ADO.NET Classes
Class Prefix for Object
DataSet ds
DataTable dt
DataView dv
DataRow drw
Connection[*] cnn
Command[*] cmd
DataAdapter[*] da
CommandBuilder[*] bld
DataReader[*] dr

[*] Each of these objects would be prefixed with OleDb, SQLClient, or some other namespace, depending on the driver used to access your data source.

We use an additional convention when working with ADO.NET objects: If a scope contains only a single instance of a particular type of object, we'll use just the prefix as the variable name. Here's an example:

 Dim dr As New SqlDataReader() Dim ds As DataSet 

Of course, if you need two or more of the same data type in the same scope, you can use the prefixes listed in Table A.7 as part of variable names.


    ASP. NET Developer's JumpStart
    ASP.NET Developers JumpStart
    ISBN: 0672323575
    EAN: 2147483647
    Year: 2002
    Pages: 234 © 2008-2017.
    If you may any questions please contact us: