Craig,

This is not aimed at you - yours was just the last message to which I could reply. . .

Menachem,

Maybe I missed it, but I haven't seen a single "standard" mentioning code COMMENTARY. I have a personal standard, which I also made a shop standard when I had such responsibility. It is along these lines:

Commentary is critical because it affords quicker program review when modifying *AND* acts as a possible check to compare that code actually reflects the (design) intention.

So *any* piece of code which does a specific (little) thing should at least have a comment line to explain the purpose/intention of the following code. Something along the lines of:

* Get the correct records for the Customer just entered
code doing so is here, possibly several lines

* Now display the initial entry form with Edit enabled
more code here, possibly several lines

In general a program seems to read nicely if there is at least 10% of such commentary.

Most of the time I accomplish this "naturally" - I typically type in my pseudo-code as comments *FIRST* before *any* coding is done. Then it is simply a case of placing the actual code under the appropriate comment.

I know that most people do NOT like typing at all (I am one of them) but I have found, possibly as I age, that this is REAL helpful 3 months or two years from the day of initial coding.

Now that it is possible, I also use continuation multi-lines for most SQL-Selects and place comments right of the semi-colon where it is helpful (as in WHERE clause items of IIF() statements, etc.

Cheers,

Jim N

>>>o Command and Functions are always in CAPS.
>>
>>Basically, the previous rule is the only one that I don't like.
>>
>>I would add:
>>- Always use () for methods, func/procs and events.
>>- Always use [] for arrays.
>>- Declare all locally used variables as local/private at the begining of each func/proc/method. Don't declare variables in other places inside funcs/procs/methods (ie: inside loops, ifs, etc.)
>>- Use FOR ... ENDFOR not FOR ... NEXT ... (this is really a matter of taste, but ENDFOR is more in the FoxPro style)
>>- Don't use "&&" comments.
>>- Don't write code lines longer than 50-60 chars.
>>- Parenthesize each condition in composed logical expressions.
>>- Don't use square brackets for character strings unless you need it.
>>
>>And for index names: if the index expression is a single field, than the name of the index is the same as the name of the field.
>>
>>Vlad
>
>In addition:
>
>When continuing on the next line, put the operator on the next line. For example use:
>
>lcVar = "This is a string that can " ;
> + "get really long"
>
>IF (a = b) ;
>AND (b = c)
>
>rather than
>
>lcVar = "This is a string that can " + ;
> "get really long"
>
>IF (a = b) AND ;
> (b = c)
>
>I've found this method to greatly increase readability.