Rules for Creating Names Adding the Personal Touch

Developers tend to have an independent streak, which often means that we like to do things our own way. Thankfully, development is a creative process so typically there are multiple ways to achieve the desired results. That's also the case with naming conventions. Even if you choose to adopt existing standards, there are plenty of opportunities to incorporate your own preferences and come up with a system that is easy for you to remember, implement, and share. But before you start customizing things, it's still a good idea to understand the basic rules and principles of naming conventions. The following sections provide information to help you to both work with existing standards and create your own. You may find that a combination works best.

Starting with the Basics

Naming conventions apply to application objects, such as forms, reports, controls, queries, and user-defined objects, as well as to Access database engine (ACE) (and Jet) objects such as containers, databases, fields, queryDefs, tableDefs, and workspaces.

Consistency is the key. As stated earlier, it's best to determine your naming conventions before you create the first object in your database so that you can apply them consistently throughout your application. Remember that even when following an established naming convention, there will be plenty of situations that challenge your interpretation of how to apply it.

Next, think KISS (Keep It Short and Simple). Although Access allows up to 64 characters for each object name, no one wants to type or read names that are that long. Plus, your application may need to interface with other programs that are more restrictive in name length. (If your object names aren't compatible with those programs, you could be in for a lot of extra work.) For example, prior to SQL Server 6.0, field names needed to be lowercase for upsizing from Access to the SQL Server. Prior to SQL Server 7.0, field and table names were limited to 30 characters and required an underscore instead of allowing an embedded space. As you can see, just because Access allows 64 characters doesn't mean it is a good thing to create 64-character names.

There have been situations with Access 2003 and WindowsXP where an excessively long path to a table name caused Access to close. If you are using Windows XP and your database is in a folder in MyDocuments, for example, that automatically adds about 50 characters to the file path.

Periods do not belong in names. Periods are a special character that can cause your code to break.

The following are some basic rules and guidelines that apply to both the name and the elements of objects:

□ Names can contain up to 64 characters (but shorter is better, as previously discussed).

□ Use complete words in names. If you absolutely must use an abbreviation, ensure that it's a standard, easy-to-interpret one. You might use FName and LName for FirstName and LastName, for example, or in a table with company details you might have field names of CoName, CoAddress, and so on.

□ Names can consist of any combination of letters and numbers. For example, in tables with multiple address lines, it's common to see Addressl and Address2.

□ Be aware: While spaces and special characters — except period (.), exclamation point (!), accent grave (v), and brackets ([]) — are all technically acceptable, they are known to create problems in table and field names. Do not use them. (We strongly advise you to remove the spaces and characters if you are going to customize and add code to work with these objects.)

If you change the name of an object, remember that the name also needs to be updated in any code, modules, or other objects that reference it.

□ Don't begin a name with a leading space. (Just don't use spaces. If readability is an issue, use case — capitalize the first letter of each word, like this: June07MarketingOutlook.)

□ Do not include control characters ASCII values 0-31 (remember that special character thing). See Appendix K to learn about special characters.

□ Don't duplicate the name of a property or other element used by DAO.

□ Avoid a series of uppercase letters — these are reserved for formal abbreviations, such as USA.

□ Names are typically singular rather than plural, for example LastName for a field or txtState for a text box.

□ Include the base name of the object(s) that it is built on, when practical and logical, such as EventCity for the field City in the table tblEvent.

□ List multiple base objects left-to-right in descending order of importance, such as tblStudentClass for a table that joins records from tblStudents with records from tblClass.

□ A name should use title case construction for the base. It is preceded by a lowercase, three-letter tag, such as in tblStudentClass, lblClassDate, or intLattePrice.

Some Additional Thoughts About Other Objects

If you are going to customize existing conventions or create your own, there are several other things that you will want to consider. The following are some of the more common objects that you'll want to have rules for handling.

Variables and Routines

The body of a variable or routine name should use mixed case and should be only long enough to describe its purpose. For example, Dim intFormCount As Integer returns the number of open forms.

Functions

Function names should begin with a verb, and it may add clarity to prefix them with an f for fnc. This can make functions easier to locate and identify when you are perusing through code. Avoid using fn_ because that is the prefix that SQL Server uses for functions. fDisplayUnexpectedError, for example, is clearly a function and not the name of a field that contains captured error messages.

Stored procedure names should begin with a verb. Having a tag precede the base name facilitates sorting — ins for insert and arc for archive, for example. When applying tags, avoid sp_, dt_, and xp_ because, again, they are used by SQL Server. fCloseAllForms is a good example of a clear and concise name.

Constants

The base name of a constant is often UPPERCASE_WORDS with underscores (_) between words. Prefixes such as i, s, g, and m can be very useful in understanding the value and the scope of a constant. For example, in the new line character string gsNEW_LINE, the g indicates that it is global to entire application and the s indicates that it's a string.

Constants should be prefixed by the scope prefixes m or g for module or global, respectively. A constant is indicated by appending the letter c to the end of the data type, or it can have the generic tag con. For the constant gintcDiscount, g is the scope, int indicates the data type, c means it's a constant, and the base name is Discount. conDiscount names the same constant, but conveys less information because it uses the generic tag. mdblcPi indicates module level (m), double (dbl) constant (c) with the base name Pi.

Classes

A class defines a user-defined object. Because this invents a new data type, you need to invent a new tag for the object. You can add a base name to the tag to spell out the abbreviation indicated by the tag. Chapter 13, for example, used the class module clsClassroom.

Arrays and Collections

An array is a variable that can store multiple values. In a fixed array, the number of rows and columns are specified; in a dynamic array, the dimensions can be established in the procedure calling the array. Arrays often use an a tag, such as aintFontSizes or astrFields.

Collections are groups of objects, such as the forms collection or a collection established to allow multiple instances of a single form. col is often used as prefix to indicate a collection. For example, mcolFormInstances is a module-level collection allowing multiple form instances.

Attachments

You can leverage Access's powerful sorting and reporting tools through the use of attachments. This also means that you need to have some control over the path and name of the attachment. Although the rules are more lenient, we still recommend following the KISS principles. Given that advice, here are the rules:

□ Names of attached files can contain any Unicode character supported by the NTFS file system used in Microsoft Windows NT or later.

□ The filename must not exceed 255 characters, including the extension.

□ The filename cannot contain paragraph marks or any of the following special characters: ?, ", /, \, <, >, *, |, and :. Although the other characters are not prohibited, we strongly recommend not using them.

Macros

A macro automates a task. It can be used alone or in a macro group, also called a macro. Macro is one of the objects listed in the Navigation pane. Each macro and macro group should have a unique name that clearly describes the action that it performs. We recommend following standard naming procedures, including avoiding reserved words and special characters.

A good example of a macro name is AutoExec. Because it's often employed at start-up, it is the most commonly used macro for an Access database. You learn more about macros in Chapter 2.

0 0

Post a comment