>My take on this would be that all you should be held responsible for is to write code that someone who knows the general syntax & commands of the given language can read. Some sort of regular indenting/spacing, meaningful variable & function names, commented where appropriate. I think the main point is, just because an expert CAN decipher IIF statements imbedded a dozen times w/ variable names & UDF's like FUNC1( para1, para2 ) strewn about within it, doesn't mean they should have to. On the other end of that, just because a beginner doesn't know what a given command means does not mean you need to place the contents of the entire MSDN help page in a comment block above it.
>
>FWIW, I had a non-programming friend at a prior job who I could sit down with, open the code in WordPad or something on her machine & talk through the logic w/ her and she could read and understand what the program was doing just because of 1) her basic propinsity for logical thinking and 2) following conventions as outlined above when writing the code. In this case, 'CASE' statements needed to be explained because a non-coder wouldn't intuitively understand the nuances of that. However, in our daily practice I believe we should be able to assume that it's safe to put that in our code w/o accidentally making it confusing for other programmers.
>
>What's everyone else think?

I agree.
The issue with CASE isn't that it's hard to understand (though it does need explaining to a non-programmer), but rather if CASE statements should do "work" other than providing a T/F return code. Should a series of CASEs under a single DO CASE actually be a "mainline" and perform the programs main work. My take is no, that CASEs are strictly for interrogation.
In my opinion any series of CASEs that do "work" is elegant in the way that a pitcher plant is elegant to a fly.

cheers
>
SNIP