Home Services Industries Showcase Library People

 
 

 

4.4.2.2 4D Development Standards

Slicksurface adheres to a set of standards and best practices when writing 4D code. Some of these standards are more flexible than others.

Variable Naming

Normally, variable naming standards are "nice," but nothing blows up if you violate them. When you use components, however, minimal variable naming standards are a must. Component variable names are not allowed to conflict with other variable names. When the component is installed, a check is made and the install is aborted if there is a problem. If you then write code with conflicting names and reinstall the component, you may find that the component will no longer install. Luckily 4D Insider provides users with a log of all the offending variables.

In general, the naming convention is as follows:

     mod__Descript_vt

"mod__" is the module prefix. All variables (and methods) in StarterKit absolutely must have a module prefix. The underscore(s) following the module prefix are important. For code that will be in a component, there should be a double underscore. Code outside a component (regular application code) should have a single underscore. This ensures that there are never naming conflicts.

The middle portion of the variable name is the descriptor. The most important aspect of the descriptor is that it be readable. It is said that code is read 5 times for every time it is written. Readable variable names save time and money.

"_vt" is the type abbreviation. The list of type abbreviations is as follows:

  • vt - Text
  • vs - String
  • vl - LongInt
  • vi - Integer
  • vh - Time
  • vd - Date
  • vb - Boolean
  • vp - Pointer
  • vx - Picture and Blob

 
Variable Declaration

Slicksurface compiles its applications with "all variables typed." This is set on the second page of the 4D Compiler settings (see pict below).

"All variables are typed" means that 4D will only accept variable declarations that are in "compiler_@" methods, with the exception of locals (but not parameters). When Compiler starts its compile process, it will look for these methods and then only recognize variables declared in them.

Most 4D developers seem to think that they declare all of their variables, but it is not until they turn on the "All variables are typed" option that they realize otherwise. If you haven't made serious use of this technique before, you will like the fact that the compiler will find misspelled variables for you.

Here's how it works:

  • Interprocess variables and arrays — declare in compiler__module_vars
  • Process variables and arrays — declare in compiler__module_vars
  • Local variables and arrays — declare in the the method using them
  • Method parameters — declare in compiler__module_params

Of course, "__module_" is the module abbreviation found at the beginning of the variable (see above).

Declaring method parameters will seem odd to any programmer who has not used "all variables are typed" in the past. The call will look something like this:

     C_STRING(sk__SKAppCode;10;$0)

Because the parameter ($0) that is being declared is not for the method in which it is being declared (compiler__module_params) but rather another method (in this case, sk__SKAppCode), the method name must be specified in order for the declaration to be understood by 4D Compiler. As a result, the method name is inserted as the first parameter in the call.

If (False) is used in the compiler methods in 2 instances:

  • To avoid methods being run if a compiler__module_params method is accidentally called in the code
  • To avoid arrays being resized if a compiler__module_vars method is called in the code

If you were to execute the C_STRING declaration shown above it would, unfortunately, execute the method sk__SKAppCode. This is an oversight by 4D because this would never be a valid way of calling the method.

 

Variable Declaration in Methods

Slightly more order has been used in declaring variables in methods. Below is an example:

     C_TEXT($1;$field_vt)
     C_TEXT($2;$value_vt)
     C_STRING(10;$3;$action_vs10)  `optional - "delete", "add", "replace" - "replace" is assumed

     C_LONGINT($element_vl;$size_vl;$i)
     C_TEXT($header_vt)

 
     $field_vt:=$1
     $value_vt:=$2
     If (Count parameters>=3)
       $action_vs10:=$3
     End if
     If ($action_vs10="")
       $action_vs10:="modify"
     End if

 
     $size_vl:=Size of array(http__at_ResponseHeaderFldName)

     If ($action_vs10="add")
       $element_vl:=-1  `create a new line...
     Else
       $element_vl:=Find in array(http__at_ResponseHeaderFldName;$field_vt)
     End if

The first item is declaration of parameters. They are declared in order, starting with $0, if it exists. There is 1 paramter declaration per line. If there is a one-to-one relationship between a parameter and local variable (which is a good idea — parameters should not be used directly), then the variable is declared along with the parameter. If anything is unclear about the calling of the paramter, then a comment is added to the line. If the comment cannot fit neatly on one line, it should be explained fully at the top of the method.

Then there is a break followed by the declarations for other local variables.

Then there is another break, and the parameters are handled. This usually means copying the parameters into local variables.

Then there is another break, and the other local variables are initialized.

Then there is another break, and the code for the method starts in earnest.

 

Compiler Settings

The following 2 images show the default compiler settings for Slicksurface applications. These compiler settings should be maintained to ensure consistent operation of the application.