>James,
>
>Just a quick remark and a question.
>
>The remark is basically that I don't believe in commenting the obvious. Now what's obvious to one person, isn't always the same to another.

Perhaps I don't understand you or vice versa. My comment was that when I'm maintaining other peoples code I really don't care if they comment or not! (well at least not very much) as long as the program uses good names and is clearly written. My points about if ... else etc. were about how easy is the code to read.

Obviously one man's clearly written may be another man's mud. But if the code is like mud AND there are no comments then I will complain-- but about the specific design issues more than the lack of commenting. There is a "How not to program" web page that I saw someplace here (or was it Wiki? Was it called "How to guarantee life long employment"?) that covers most of my complaints.


>
>The question is, "What design methodology do you use?"
The question is quick but maybe you can be a little more specific: design methodology can refer to anything from creating a functional specification, to ER diagrams, to flowcharts before coding, to CASE tools...to ... you get my drift.

One thing to remember, the code maintainer may not have access to your design tools. I.e. the flowcharts, ER Diagrams, and Rational Rose and all the rest may either not exist anymore or be in versions that are now longer compatible with the current software. The company may have used allclear to do it's flowcharts, switched to Visio and then gone to XCASE. The relations that the developer carefully entered into the database container may be gone like the wind. The documentation at that point may be obsolete or even lost. But a few good comments in the source code will be around as long as there is source code to maintain!

>However, I believe that anyone in a position to be examing or modifying the code should have some degree of facility with programming.
It's hard to imagine anyone arguing with you on that point. Did anyone? :-)