Naming Conventions

From 4DWiki

[Naming Conventions at primary Wikipedia site.]

There isn't anything special about naming of variables in 4D when compared to other languages. All the obvious techniques apply to create variables which are readable and useful. Some 4D specific concepts are:

[edit] Spaces

Create field and table names without spaces, even though 4D allows it. This makes them easy to double click in the 4D IDE and is much more readable.

Foreign language versions allow the use of special characters in variable and field names, such as umlauts (üöä), accents (éÈ) and other uncommon characters. Also hyphens can be used as well as paranthesis. These characters also make the selection by double click impossible and should be avoided.

It is good practice to stick to the base characters (a-z;A-Z) numerals (0-9) and the underscore for all naming of objects, variables, fields, etc. in 4D.

[edit] Typing

When 4D is running uncompiled it is a weakly typed language. Therefore some developers put the variable type within the name of the variable (eg. StudentName_t). When compiled this isn't necessary since the compiler is able to spot uses of a variable with the wrong type.

Refactoring can be efficiently and painlessly done using the tool 4D Insider.

There are many different possibilites for naming variables, based on personal preference, most developers use either pre- or suffixes to the actual variable name.

Using a prefix makes it easier to ensure proper variable typing as it allows you to spot automatic mistypings by the compiler in compiler methods.

Example:

Compiler defaults to real numbers for numeric variables and generates this typing directive:

C_REAL(l_longvar)

Searching for "REAL(l" and replacing it with "LONGINT(l" in the compiler method returns

C_LONGINT(l_longvar)

[edit] Scope

Because 4D has no concept of packaging scope for variable name space, it is necessary to artificially create such a thing by the use of variable naming. This isn't necessary for local variables (which have scope of the current method), but process variables cannot be restricted to (say) the methods relevant to students. Having a process variable called "Name" is dangerous and liable to collision with company name. So one technique is to give every process variable a scope prefix. For example "Student_Name".

By using the same technique for method naming, logical groupings can be created between 'packages' in 4D. Process variables are associated with methods. Finding a variable called Company_Name in a method called Student_GetAmountOwing would be considered a programming mistake. Instead, the variable would be called Student_CompanyName, where the prefix shows that this variable is meant to be used within the Student 'package'.

There is even a plugin for SanityCheck which helps enforce this.