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

Peter;

I could be off on the date but it seems like Apple adopted an Interface standard in 1985, which was created by someone who published a book on the subject. Microsoft and Apple around 1990 agreed upon the standard. Where it went from there I do not know.

There is a book on the Microsoft version:

"The Windows Interface Guidelines for Software Design" -
Microsoft Press ISBN 1-55615-679-0


Tom