NamingVariables

MapBasic doesn't put a lot of restrictions on variable names, but if you're writing anything more complex than a one-shot scrapplication, there's several good reasons why you should adopt a variable naming convention. A good system can tell you at a glance the VariableScope, the VariableType? and differentiates a program variable from a table or field name or a DefinedConstant?. This practice promotes the principle of SelfDocumentingCode, a factor that strongly affects the maintenance phase of the ProgramLifeCycle? -- the phase commonly acknowledged as the most expensive.

One convention you might use is based on what's known as Hungarian notation. Variableas are made up from normal words or obvious abbreviations, with their first letters capitalized. Variables are prefixed by a code indicating the scope and their data type. Underscores are not used except in the case of global or module scope variables. For example, an integer variable that keeps track of a record count might be named nRecordCount. Abbreviations may be used to make this nRecCount, but nRC is not a good choice. The guideline should be that anyone reading this code should be reasonably able to get some idea of what the variable is used for.

Exceptions to the rule exist as well (of course.) Simple counter variables like i, j, k, and string pointers like p are employed where their use is obvious.

Prefixes that indicate the variable type are as follows:

a      Alias
b      Logical, i.e. Boolean (TRUE or FALSE)
brush  Brush
d      Date
f      Float
font   Font
i      SmallInt
n      Integer
obj    Object
pen    Pen
s      String (fixed or variable length)
sz     String (fixed or variable length)
sym    Symbol
t      User-defined type (UDT)

Global variables are differentiated by a "g_" placed before the type indentifier. For example, a global string variable might be g_sCensusTab. Global variables declared with "Dim" instead of "Global" are global only to the functions in the module in which they appear, and might be prefixed with "m_" instead of "g_" to indicate their more limited scope.

If you don't like the _ then lose it and just add either the g- or the m- as here: mnNumPages, gsymFind.

All this extra work makes a variable's purpose and function more obvious and reduces the very real danger that a variable may inadvertently be given a name that conflicts with a table or field name. When this happens, the resulting bugs can be very hard to track down.