In last month's issue, I talked about ways to format Xbasic code.  I also made a reference to how objects could be named.  This month, I'll talk about different naming conventions, and why they are useful.

Ever since the introduction of Windows 95, we have gained the ability to use long file names.  While this can be an advantage, there are also times when this same feature can cause problems.  This also holds true for naming objects within a program, such as indexes, forms, operations, scripts, etc.

There are three basic reasons to adopt naming conventions:

•	Use names that do not cause problems with the program.
•	Use names that make it easier to design an application, and follow what it is doing when you look at it sometime later.
•	Use names that are unique enough so they can be found easily with the documenter without finding other names you don't want.

The first is certainly the most important.  However, you might wonder how something as simple as a name could cause a problem.  To explain, here is a list of name types, and the problems they might cause¹:

FIELD NAME	This name has a space.  Alpha will sometimes change the name to FIELD_NAME.  When that happens, the two names don't match, which can cause scripts to fail.
TABLE NAME	Another name with a space.  Alpha will sometimes change the name to TABLE_NAME, which could cause the same problem mentioned above.  Specifically, this can cause an error when scripting an Xbasic append operation.
LONGINDEXNAME1 LONGINDEXNAME2	These two names are long, and the first 10 characters are identical.  This might cause a problem if the index names are truncated (which could result from an append operation, or other operations involving the data dictionary).
LABEL	This is one of many "reserved" names that Alpha uses (see Reserved Names).  These names should not be used for naming any objects (fields, layouts, script variables, etc.).

Next, names can make an app easier to design and understand.  These suggestions are more subjective, but the logic behind them makes sense:

•	Use identical prefixes for similar type form names.  For example, MENU_MAIN could be your Main Menu.  Then MENU_UTIL could be for utilities, MENU_REPORTS could be for reports, etc.  Another example would be to preface dialog forms with a D (D_DATE_INPUT). By using similar prefixes, all similar forms are in the same area in the Control Panel.  This can be helpful with an app that has a lot of forms.
•	Don't use identical names for forms, reports, and operations.  While Alpha will permit this, it can be confusing with a large app.  For example, if you have a form and saved append operation with the same name, and you want to open the form from the Control Panel, and you're not quite paying attention, you could accidentally run the append (I'm sure you can think of other mistakes that could be equally as disastrous!).
•	Finally, making all of your names for layouts, fields, indexes, and variables unique will make it much easier to debug your application.  By using unique names, your scripts (action scripts or Xbasic) will be less confusing and searching for text with the documenter will be faster because the search will be more accurate2.

Keeping the names unique is not as simple as it first seems but it's not difficult either. Here are a few guidelines that will help:

•	Try to use two "words" to create each name.  The chance of repeating the same sequence of two words is much lower than with one word.3
•	As an alternative, you could use single-word names such as ADDR1 and ADDR2, as long as you don't also use something like SHIPPING_ADDR1.
•	Remember that searches are generally for text strings, so a search for "rep" will also turn up words like "preparing".
•	Since index and variable names are often used in conjunction with field names, it's wise not to make them the same as field names.  However, if the name is similar to a field name, it makes it easier to know what field the index or variable is referencing.

After a number of iterations, I've finally settled on the following for all new applications:  All field names end with the letter "F" and the letter "F" is changed to "_" (underscore) for index names or "V" for variables.  Putting the special character at the end of the names instead of the beginning makes them easier to read.  In fact, the underscore was specifically chosen for the index names because it is the least obtrusive.  The only drawback to this method is that the default label name usually needs to be changed.  I also try to make field names two-word names whenever possible, even though this sometimes means abbreviating the index name to keep it under 10 characters long (as noted above).

Here's one last suggestion on field names. Give careful consideration to the first part of your field name.  Putting the noun part of the name first is usually best.  In Version 5, you will be able to sort the fields alphabetically when viewing them in the drop-down list in layouts, so having similar "prefixes" will be very helpful for grouping common fields.  If you want to group all your "name" fields, you would use something like NAME_FIRST and NAME_LAST rather than FIRST_NAME and LAST_NAME.

Remember, these guidelines are not necessary when designing an application and can also be modified to suit your needs.  However, the reasons behind them are sound, and I have found that using them makes my life considerably easier.