Erik,

I agree that descriptive method and parameter names are extremely valuable, but if (for example) I've got a method called ImportNewCompanies which accepts the parameters toRSImportData, toRSMappingData and tcDatabase, in 6 months, I really want to be able to quickly find out what the format of the ADO record sets should be and what the method will return in terms of success or failure information.

I could troll through the code to find this out, but the whole reason I defined the interface and then coded and tested the method was so that to do the import, all I had to do was pass the relavant parameters and read the return value.

Cheers,

Andrew

---

>Seriously, comments that explain parameters follow the same guidelines, IMO. With descriptive variable names, often a comment explaining the purpose is completely unneeded.
>
>I don't have my code reviewed by peers as much as I would like, so I don't really know if my code is horribly unreadable- but I use comments pretty sparingly, and rely heavily on descriptive routine and variable names to explain what's going on. I usually reserve comments for unintuitive logic sequences- the rest is simple and understandable by design. I've seen some really horrible code that's meticulously documented, and it's still difficult to understand.