In Control

Hi Kim,

Although I try and apply a consistent convention, I confess that how I go about naming does change with time. I like to think of it as evolution rather than being inconsistent. Certainly, within any one program I try to be consistent.

I generally structure my programs in an "object based" fashion. While SPLat does not enforce any such thing (spaghetti code is perfectly legal), some self-discipline goes a long way.

Typically an "object" will consist of a block of code containing a task that runs under MultiTrack, plus several subroutines (methods and property accesses in OO languages) that access the "object's" variables and manage semaphores. The object will have a name, say Pump Control. Every symbol within that object will have name or label that contains a 3 or 4 letter abbreviation of the name followed by an underscore. I make sure that no two objects have the same "short name". For example, the subroutine to initialize the object would be called PMP_Init.

For variable data (RAM) I use a convention where the short name (PMP_) is included, with a lower case prefix denoting the variable type, say fPMP_CycleCount for a floating point variable, bPMP_Status for a byte variable or sPMP_Busy for a semaphore.

In keeping with the Object Based Programming principle of encapsulation or data hiding, nothing outside the object is allowed to directly access the object's variables. This may result in more lines of code but will give a much more robust program. Anyone outside the object must use subroutine calls to purpose written code within the object. For example, to find out if the pump is busy do a GoSub to PMP_GET_Busy, which will code as

PMP_GET_Busy:     RecallS     sPMP_Busy

                  Return

While this may seem like extra work, it means that the caller need know or assume nothing about how the PMP_ object works internally (including how it stores data). PMP_ can be totally rewritten, and as long as it's "interface" to the outside world remains consistent, no other part of the program need be affected. The complementary operation would be a property SET subroutine. Thus the PMP_ object might have the following interface routines:

PMP_Init

PMP_SET_RunOnTime

PMP_Forward

PMP_Reverse

PMP_Stop

PMP_GET_Busy

PMP_GET_Fault

PMP_Reset

In the header comment at the start of the object's code I will document all the interface calls to create an Interface Specification.

The final thing I do, very consistently these days, is always include the optional colon in a line label, e.g.

sPMP_Busy:     defSEM

This makes it every so much easier to find the line, rather than references to it, using the editors text search.

I hope this makes sense to you.