In previous chapters, we discussed naming conventions for Tables, Pages, and Reports. In general, the naming guidelines for NAV objects and C/AL encourage consistency, common sense, and readibility. Use meaningful names. These make the system more intuitive to the users and more self-documenting.
When we name variables, we must try to keep the names as self-documenting as possible. We should differentiate between similar, but different, variable meanings, such as Cost (cost from the vendor) and Amount (selling price to the customer). Embedded spaces, periods, or other special characters should be avoided (even though we find some violations of this in the base product). If we want to use special characters for the benefit of the user, we should put them in the caption, not in the name. If possible, we will stick to letters and numbers in our variable names. We should always avoid Hungarian naming styles (see https://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx); keep names simple and descriptive.
There are a number of reasons to keep variable names simple. Other software products with which we may interface may have limitations on variable names. Some special characters have special meaning to other software or in another human language. In NAV, symbols such as ? and * are wildcards and must be avoided in variable names. The $ symbol has special meaning in other software. SQL Server adds its own special characters to NAV names and the resultant combinations can get quite confusing (not just to us but to the software). The same can be said for the names constructed by the internal RDLC generator, which replaces spaces and periods with underscores.
When we are defining multiple instances of a table, we should either differentiate clearly by name (for example, Item and NewItem) or by a descriptive suffix (for example, Item, ItemForVarient, ItemForLocation). In the very common situation where a name is a compound combination of words, begin each abbreviated word with a capital letter (for example, NewCustBalDue).
Avoid creating variable names that are common words that might be reserved words (for example, Page, Column, Number, and Integer). C/SIDE will sometimes not warn us that we have used a reserved word, and we may find our logic and the automatic logic working at very mysterious cross-purposes.
Do not start variables with a prefix x, which is used in some automatically created variables, such as xRec. We should make sure that we can clearly differentiate between working storage variable names and the field names originating in tables. Sometimes, C/SIDE will allow us to have a global name, local name, and/or record variable name, all with the same literal name. If we do this, we are practically guaranteeing a variable misidentification bug where the compiler uses a different variable than what we intended to be referenced.
When defining a temporary table, preface the name logically, for example, with Temp. In general, use meaningful names that help in identifying the type and purpose of the item being named. When naming a new function, we should be reasonably descriptive. Don't name two functions located in different objects with the same name. It will be too easy to get confused later.
In short, be careful, be consistent, be clear, and use common sense.