I agree Roxanne. I guess I was being lazy (as usual) when I relied.

Cheers,

Jim N

>>* 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.
>
>Hi Jim,
>I agree for the most part on inline commentary in this manner. This was the way I was formally taught to document code, but I found it led me easily to a bad habit. The bad habit being that my psuedocode typically states *what* I am doing as opposed to telling me *why* I am doing it. I've found that at the time I'm writing new code, I'm running full speed ahead and know easily *what* I need to do next. But when somebody else looks at that code, or if I go back and look at it some time later, I tend to look at the *what I am doing* comment and say "Duh... I can see that" So now my own standard is to key in my psuedocode in a different form, so as to explain *why* I need to do a particular step. i.e. -
>
>* Get the correct records for the Customer just entered (instead of this)
>*!* Retrieve customer records for id user entered to populate grid
> code doing so is here, possibly several lines
>
>FWIW - In regards to other parts of this thread, I think putting the AND/OR operator at the beginning of a continuation line is more readable than putting it at the end.