Standards of Nomenclature and Semantics

When coding in any language, on any platform, it is necessary to employ a great deal of thought in terms of what you are going to name your components, variables and objects. The following document is not a rigid standard that must be stuck to, but rather a guideline that will attempt to explain most of the steps that are necessary in writing understandable code (and when I say understandable, I mean understandable by other coders, not just you).

Descriptive Names

The first thing to discuss under the topic of nomenclature and semantics is descriptiveness of names. Something that many people do not understand (Microsoft included, in many cases) is that all names MUST be descriptive. For example, consider the following code:

   Dim Date1 As Date, Date2 As Date
   
   Date1 = Date
   Date2 = DateAdd("d", 7, Date1)

On its own, this code makes perfect sense: you assign today's date to Date1, and then add 7 days and assign this to Date2. Thus, this code is seemingly OK. However, in a situation where you have a lot of code in one routine, and the dates are declared and assigned at the top of the routine, there is no way that you or anybody else is ever going to remember which variable is which or how they are used.

Now consider this code:

   Dim dtToday As Date, dtNextWeek As Date
   
   dtToday = Date
   dtNextWeek = DateAdd("d", 7, Date1)

As you can see, it would now be clear to anybody what the purpose of these variables are, wherever they are in your code, and it is much easier to remember which is which while coding.

Naming Files

While the standards of naming files may be obvious to many people, it is all too often that you see projects with forms called 'Form1', 'Form2' etc. and modules called 'Module1'. Thus it is necessary to explain the naming standards for files.

The generally accepted method for naming files is to choose a descriptive name for the file, and then prefix it according to the file type, using the correct prefix from the table below:

File Type	Prefix
Form	frm
BAS Module	mod
Class Module	cls
User Control	uc

For example you may have the following files in your application:

• frmMain
• frmAbout
• frmPrintBookings
• frmPrintInvoice
• frmCalendarView
• modMain
• modSettings
• modDeclares

From the names of the files, it is obvious what the purpose of each is, and thus the code is easily maintainable.