>>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.
>
Basically, my view is that highly cohesive code tends to be shorter and often doesn't need one comment to describe it if the name is descriptive. Sometimes listing the incoming parameters can be helpful.
>>
>>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.
>
I speaking about the approach to the design process. You sound like you use Top-Down like I do.