Tag Archives: Variable Scope

Formatting Phone Numbers – followup

The code which I originally put together on my previous blog entry was US centric…I have adjusted it to make it more flexible, and to be able to handle more countries.

The parameters have changed.  1) End users input 2) expected number of digits (after removing all other formatting) 3) Description of the target format (& denotes a substitution at that position.  The single digit following an & denotes how many numbers to use from the phone number in that spot.

The full code can be downloaded from here

Calling the routine

Here is the code

Saving state/data without defining a bunch of temporary variables

2013-11-14 00_42_02-LANSA Editor - AJBTEST ( Form_ ) - test


Variable Scope

In RDMLX (The LANSA language), variables have a global scope. This means that it’s really easy at times to accidentally clobber a field which you are using, by using the field for more than one purpose. It can be argued that all fields should only be used for one purpose in a program, but there are scenarios where this can happen. E.g. You may be using a field to represent the selected value in a drop down list, and you may also be using the same field to populate the value when building the list.

Global variables have historically been a cause of subtle bugs. A couple of options exist to try and alleviate this problem. Any code that would be better with a local variable scope can always be externalized into a reusable component (The first option). This will also go a long way to minimize coupling. However, if you do not want to re-architect your program, but still need to prevent your variable from becoming contaminated, you could always backup your variables at a convenient location and restore it later when you need the saved values back (the second option).

Use a List

If the save and restore have to handle more than a few variables, it becomes cumbersome if you are just using temporary variables to store the data.

The solution shown in the image above defines a working list with one record. Then when you want to backup the data, you merely do an ADD_ENTRY to_list(#LISTNAME). And voila, you have saved the current state of these fields. Once you are ready to restore the state of the fields, you can do a GET_ENTRY number(1) from_list(#LISTNAME) and you variables have been restored.

This techniques tends to reduce the need for work fields, and can reduce the coding required to accomplish the same task.
Less work fields and less code = less bugs.