> HRESULT error = e.GetErrorCode(); // 23 = data error I do the exact same thing, but for slightly different reasons. Even if the error has a mnemonic defined, and even if the code is using that mnemonic, that comment can be handy when debugging, since comments are more easily accessible there than grepping winerror.h.
>Whether these comments were/are useful to anyone else, �I have no idea (but >probably not!). I have to admit that my general commenting style only infrequently aspires to help anyone but me. Both my commenting and variable naming tendencies have changed with the onset of old age. Struggling to understand large bodies of code that I wrote 15 years ago is a humbling experience, but one that provides useful feedback -- I could immediately see a pattern in those parts of the code that I could readily re-understand, as opposed to those that were opaque. These days, my variable names are longer, and I even carefully name index variables (iFile instead of i, if I'm stepping through files, for example). Functions of non-trivial complexity have pseudo code in a comment at the beginning, which I find provides an order of magnitude speedup in comprehension of code that I've written and long forgotten. My comments that are aimed at others are almost in the service of meta-programming -- the coding work that has nothing to do with producing the desired behaviour on the screen and everything to do with maintainability. For example, if I'm writing in C++, I can use a language construct to say "only function A should call function B". If I'm writing in C, I will use a comment to note that fact. - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
