Peter,

There is nothing wrong with having your own standards. In fact, I applaud that you have some. Far to many programmers don't use any standards. There is nothing wrong with the way you do anything...it's just a different way. I have just added a couple of comments. Either it's addtional things to think about or explains why I do things how I do them.

>
>

*   Yours...
>lnMyNum = 12
>lcMyString = "ABCD"
>lnCounter = 0
>
>*  Mine...
>lnMyNum    = 12
>lcMyString = "ABCD"
>lnCounter  = 0

If you need to add a new variable that is longer than the existing ones, it takes time and effort to go back and add spaces in the existing lines.

>
>

*   Yours...
>lcCommand = "Today is Wednesday, October 16, 2003" + ;
>    "The time is 2:00 PM"

Acutally, mine is

lcCommand = "Today is Wednesday, October 16, 2003"  ;
    + "The time is 2:00 PM"

>
>You state: Do not use comments at the end of a line with &&. Each comment should be on a line by itself. I can't think of any reason for this to be a 'standard'.

It's called readability. This part of my standard came straight out of Code Complete. It also originated before we had color-coded editing in VFP. It made it much easier to find comments because they weren't "hidden" at the end of a line. However, I still find this holds true today when reading printed code.

>
>You state: All input capable fields should use Select On Entry. This can't be a coding standard. It's a functional requirement ('Select on Entry' or not), that's dictated by the functional designer, not by the programmer.

That may be more functional design, but so is the section on when to use a particular form object. I put it in the standards because it's in Windows standards and that way it was documented.

>
>About naming of variables:
>- ldStartDate could also be ldStart
>- lcMsgText could also be lcMsg
>- lnLowValue could also be lnLow
>Moral: Why use Date in the name if the 2nd char already indicates it's a date?!

I agree.

>
>I don't use the m like in lmMsg. Instead, I'd stick to lcMsg. What matters is that it's a character string. The source is (most of the times) not important and it may even change over time, e.g. when the field type is changed.
>In a same vein, I don't use the i like in liAge. Maybe (maybe) I'd use it if integer versus numerical is important to realize. But in the case of an age, what matters is that it's a number.

I use m and i. It makes it a bit easier when reading code to know what the value can or can't be or what field type the variable is tied to. I wouldn't use Integer for age. Why? Integer takes 4 bytes, a Numeric (3) takes three bytes. Again, personal preference.