Menachem suggests:

> First character of variable name indicates scope as follows:
> L = Local
> G = Global (Public)
> P = Private
> T = Parameter (I never distinguish between private and local parameters because I only use Local parameters)

I agree with all of these and use them religiously. There is
one standard suggested by Codebook which I have changed, however,
and that is the practice of putting DEFINE's in all caps. What
is different about a Define (besides being a constant) is its
scope. It is available some places and not others depending on
how the Include statement is used. So I propose treating
DEFINE names like other variable names with the prefix "h"

I wrote this a while back:

TOP THREE REASONS FOR USING AN "H" BEFORE A #DEFINE CONSTANT

3. It's the letter after G (for global).

2. It's the letter that looks most like "#".

1. Because we use an "H" as the extension for a Header file.



>o Second character is the data type. In the rare instances where the data type is not known beforehand, use 'U'. Otherwise, use the data type character used by the TYPE() function (e.g. C = Character, T = DateTime, etc.)
>
>o Rest of the name is something descriptive. Long variable names are OK but I try not to go overboard.
>
>Field Naming Conventions
>~~~~~~~~~~~~~~~~~~~~~~~~
>Basically, do the same thing as done for variables but no scope character.
>

I definitely agree with using type characters on field names.
For instance I have adopted the practice of naming primary
keys as "i" + FILENAME, e.g. iACCNTS, iOWNERS, iORDERS, etc.
I like this much better than "iACCNTS_key", "Owners_key", etc.
Notice that I put the table name in all caps, even when used
as part of a field name. Tables and other files are so important
that references to them should stand out in the code.

If I have a primary character field which accompanies the
primary integer key, than I just use "c" as the prefix.
Thus my Association file has fields "iASSOC", and "cASSOC".
I never have to wonder what I called the field name this way.

And following the general logic that important things should
be capitalized, I never capitalize key words. Key words are
key words. We all know them (most of them anyway) and we are
not going to misread them in code.

Consider these two code samples:

First the traditional approach:

IF SEEK(curSelect.Key,"Owners","iOwners")
THIS.PARENT.txtOwners.VALUE = ;
Owners.cOwner_num + " " ;
+ Owners.cName + " " ;
+ Owners.cRCI_Num + " "
THIS.PARENT.txtOwners.SetColor()
ELSE
THIS.PARENT.txtOwners.VALUE ;
= goStrx.GET(".")
THIS.PARENT.txtOwners.SetColor(RGB(255,0,0))
ENDIF


Now, the alternative:

if seek(curSELECT.Key,"OWNERS","iOWNERS")
this.parent.txtOWNERS.value = ;
OWNERS.cOwner_num + " " ;
+ OWNERS.cName + " " ;
+ OWNERS.cRCI_Num + " "
this.parent.txtOWNERS.SetColor()
else
this.parent.txtOWNERS.value ;
= goStrx.get(".")
this.parent.txtOWNERS.SetColor(rgb(255,0,0))
endif


Take a moment to get over the fact that it looks different
than most FoxPro code (it looks more like "C" code :).
What is important to you when studying this code? The
words "SEEK", "IF", "ELSE", "THIS", "PARENT"? Really??
Is that the part you might misinterpret?

You get my point. Fortunately "Beautify" swings both ways.

Peter Robinson


P.S.
"cOwner_Num" above should really be "cOWNERS" but it
got named before I settled on my standard.

Peter Robinson ** Rodes Design ** Virginia