| 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. TIP 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: 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 TIP 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. | 
