>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.

Well, I do indeed take that time and effort. And when the longest variable is removed, then I also take the time and effort to shrink the rest. No problem for me and it should be no problem for anybody else.

>>
>>

*   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"

Yes, sorry. I guess we need an additional debate over the (dis)advantages of having the + at the beginning or at the end.

>>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.

In the old days? Okay. But these days, with code-coloring I think it does not hold true. There are many situations where it's the comment to the right that makes reading far easier, like...

private gcSystem	&& Name of the app
private gcMaintitle	&& Appname + version
private gcAppDir	&& Directory containing highest level prog
private gcPriv		&& User privilege string
private gcDataDir	&& Data root directory

>>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.

Do you have a reference to these Windows standards? In VFP, the default for thisform.SelectOnEntry is False. Anyway, I only wanted to make clear that some standards are about how to program and others are about what to program. But of course, both need standardization.