ANSI Standard PL/B Language and Visual PL/B

PL/B FIELD NAMING CONVENTIONS

Every MMCC program uses a relatively standard method for naming fields and variables. Although structured, we try not to be overly rigid. The standards cross all application systems and are generally consistent from the earliest programs of the 1980's and even back to the early 70's.

This article covers FIELD NAMING conventions modules.

---

Topics

• General field name/label conventions
• New style labels
• Local Variables
• PLFORM Object Names
• Case Sensitivity
• See the Standards Index for other topics.

---

General Field Name / Label Conventions

MMCC has been writing PL/B programs since the Datapoint days. That means that many of our programs go back to the time when labels (field names) were restricted to 8 characters. We've used the Sunbelt compilers and development environments since moving to PC's in the mid 80's. Sunbelt allows at least 32 characters. Compiler directives can make the limit even larger!

In the "8-character" days, our practice was to try to make the first two bytes identify the family or group of related variables which the label belonged to. Data files were all given a 2 byte identifer (sometimes 3 bytes). That made a good prefix for variables belonging to that file. For example:

.........
.    Address List Master file
.
ALFILE     FILE
ALNIF      DIM   1      ;error flag
ALRECKEY   DIM   9      ;packed up record key
.
ALKEY    LIST
ALCLASS    DIM   2
ALID       DIM   5
ALLOC      DIM   2
         LISTEND
.
ALRECORD LIST
ALSTATUS   DIM   2
ALNAME     DIM  30
... etc....
AL_DOT     DIM   1
         LISTEND

General working variables typically have names starting with WK, work areas for saving tempory values may start with SV. You can see the pattern.

New Style Labels

With the general move to PLBWIN, we began to abandon the old, short label style. The two character prefix has been retained, but we now generally include an underscore after those 2 bytes. We also make labels longer and use other special characters.

Local Variables

The PLBWIN compilers recognize a label which begins with a "#" pound sign as a "local variable" in the context of the source code unit. This is primarily used with INCLUDE units. If you use the varible WORK_NAME in the main line, then also have that variable in an INCLUDE unit, it results in a duplicate name error. That's because the include becomes part of the source code stream as the compiler assembles the components into a single program.

"#" variable names are transformed at compile time to begin with the unique sequential letter code of the include unit. This makes the variable name unique to the compiler. WORK_NAME in the mainline and #WORK_NAME in include "A", and #WORK_NAME in include "B" are all unique to the compiler. The compiler assigns a letter to each INCLUDE in the order in which it is encountered. When include "Z" is used, the letters start over with "AA", "BB", etc. Every INCLUDE thus has a unique identifier.

PLFORM Object Names

All of the MMCC PLBWIN programs are build around the forms designer. Labels in these forms are changed from what the designer starts with. First, a prefix is established for the form. Second, the long descriptive words (i.e. StatText) are reduced to things like ST.

The prefix for forms has been standardized as Fn_ where the "n" is the number of the form within the mainline program. Most programs have only one form so the prefix for all labels in the form is F1_. If other forms are used in the program they are given prefixes F2_, F3_, etc.

Labels in the PLFORM are written in upper and lower case and usually referred to in that way in the programs. (See more on case below). When a descriptive static text is paired with an edit text, they are given the same name.

Typical labels would be:

F1_Window              Window object
F1_ST_ClientName       StatText object (part of pair)
F1_ET_ClientName       EditText object (other part of pair)
F1_Radio_Alpha_Seq     Radio button
F1_Radio_Account_Seq   Radio button
F1_Check_Hardcopy      Check box
F1_LV_Names            List View
F1_DL_Names            Data list
F1_Combo_Names         Combo box

Case Sensitivity

MMCC programs are generally NOT CASE SENSITIVE.

The Sunbelt compilers default to being NOT CASE SENSITIVE. (This can be changed with a compile time option.)

MMCC DOES use case in some other ways. The ancient (1983) text editor we tend to use IS case sensitive. We take advantage of that in one way: Execution labels are always written in pure lower case.

Reference to execution labels are written in UPPER CASE. The objective is to make it easy to find a code segment in a large program using the editor. We might find 20 references to the routine CALCULATE_AGE in a program. If we want to find that routine while in the editor, we search for CALCULATE_AGE Being case sensitive, the editor will find each of the references to that label. It could take forever to find the routine itself.

BUT... because the execution labels are always written in lower case, we can use the editor to search for calculate_age. The only place we use the lower case label is on the routine itself so the search goes immediately to the routine, not to all the places we use it.

For this to work, it's important to follow the rule: Pure upper case when an execution label is USED. Pure lower case where it names the routine.

Return to Standards Indexfor other topics.

---

v1.10