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?


>>SNIP
>>
>>Hi Peter,
>>
>>First let me say clearly that when it comes to discussions like this (coding preferences/standards) I take nothing personal.
>>
>>>
>>>>And I don't believe it's legitimate to "expect that the next developer in line will also be a professional" if you mean one with xx years experience. A novice to VFP could still be a "professional developer".
>>>
>>>Agree partly on this one. Did I mention xx years of experience? No. But although a novice may be called a professional just because he/she earns a salary with developing in vfp, I do not feel urged to write code in such a way that is understood fully even by a real novice. Do you?
>>
>>I feel an urge to write code in such a way that it is clear what it is doing and to remove any need for a reader to go back to prior reviewed code to see certain things (which alias is now selected, or the code is finished with this table, as examples). And I don't see how this can hurt the "professional" reader unless they worry about the wrong things.
>
>Yes, but to whom must it be 'clear what it is doing'? What level do you expect of the next developer? Are you coding with the novice in mind, or do you expect at least an intermediate level? I'm of opinion that we are allowed to expect at least an intermediate level. If the owner of the code (e.g. a company) wants to take the risk of hiring a novice (a nephew of the manager perhaps?), then it's not my responsibility anymore.
>
>
>>>
>>>
>>>>In my opinion minimum typing and minimum lines does not equate to a "professional developer".
>>>
>>>Agree on this one. Did I plea somewhere for minimum typing and minimum lines? My code contains a lot of empty lines, for clarity's sake.
>>
>>No you didn't. But others do, so I mention it as a big (main?) issue for some people.
>>Blank lines are almost free to code < s >. And even there I bet there are some who view this as "wasted space/keystrokes", forcing them to prematurely scroll and stuff like that.
>>
>>Basically, I take other people's code as it is and try to work with it, to the point of trying to conform to their style regardless of my 'standards'. So I may not be as 'fixed' in this as I sound < s >
>>
>>cheers