Re: Naming Conventions (was RE: Subroutines vs Subprocedures (was RE: Indicators))

Hi Charles,

> I was leaning toward the following: g prefix for globals, w prefix for local
> and p prefix for parameters.
>
> But I really like your idea of using my to prefix locals and I think wk for
> globals would be fine.
>
> However, I'm wondering about prefixes for parameters.  I feel a need to set
> them apart from the regular variables.   But I never really like the idea of
> using a p prefix since that's so often used for "pointer".  Also, it would
> seem that I'd want to differentiate between local and global parameters.

We use:

    wk = (global) work variables.  It might make sense to use
           "gl" instead... though for us, gl refers to fields
            in the general ledger file.

    ww = (local) work variables -- though, as I've said previously,
           I'd use "my" if I could do it over again.

    pe = parameters that are input into the routine.  i.e. this is
           used for fields in a procedure interface or fields in
           an *ENTRY plist, but not used as outgoing parameters
           when calling something else.

    p_ = pointer...  although most of our conventions specify where
           a variable COMES FROM, this one specifies a DATA TYPE.
           Why? Well, it's assumed that pointers will always be
           work variables. A pointer almost always points to another
           variable's storage.  Therefore, we use a separate prefix, but
           the rest of the variable name is the same.

           for example:

               wkString  might be the name of a string variable and
               p_String  might be a pointer that points to it.

    pr = fields that are defined in an external print file.

    sc = fields that are defined in an external display file

    ds = data structure. I don't really know why we use a separate
           prefix for these, but we do. I guess it's to clue the
           programmers in on the idea that the data in this variable
           is directly related to other variables.

           Now, with qualified DSes, I don't bother with the "ds"
           prefix anymore. :)

(other) = each PF on our system has it's own 2-digit prefix so that
    field names never conflict.  (LFs use the same prefix as the PF,
    if there's more than one PF, each field is named according to
    the PF it comes from.)

We do not have separate prefixes for global vs. local pointers or global
vs. local parameters. It's possible that this is a flaw in our system,
though it hasn't really caused us grief.

Using a separate prefix for each PF isn't really needed anymore with the
prefix capabilities of the language, but it's too late for us to change at
this point -- we'd lose consistency if we did.