>Just on the point of commenting I want to add. I was fortunate to work with the code of Mike Asherman in my previous work (I haven't seen him here lately and started to wonder how he is). He writes comments almost for every line of his code and really great comments. I learned a lot from him and while back admired his style, though on the same page he had a tendency to overcomplicate some things...
>
>I saw good comments in Doug Henning's code as well when I was working on RI handler...

There are several types of comments. On mandatory ones, I would certainly mention about those that are specific to some framework logistic, for example, where it would make sense to mention them in the code. For example, a framework does things in a certain way. But, if you need something that is not supported in it, this is usually where you would have to tweek the code a litte bit to achieve what you want. So, the next developer would wonder why this has not been done the generic way. Then, the comments are really mandatory in that particular location.

Additionnaly to that, commenting pretty much special pieces of code and things like that would also be a must. But, one good thing about naming convention, is it allows to have less comment and still provides good coding style which is easy to understand. I don't want to talk against some other technologies, but for example, whenever you go on Google and start doing some searches about .NET, you will find a lot of samples where naming convention is not existing. Variables and properties such as I, J, da, ds and things like that don't mean anything to me. But, when you use lnCounter, lnCounter2, loDataAdapterEmployee and loDataSetEmployee, this is a little bit better I would say. That is why I asked YAG in the interview if he was planning to release a version of the codebook for .NET. That would have been great. Coming in from VFP, I was lucky to benefit of that. This is probably one the great learning materials I remember since the debuts of my work in this business.