> Hungarian notation is almost universally hated by people with lots of experience Make sure we do not confuse *experience* with *age*. Lots of the "older" crowd that I know, that were coding before the advent of (reverse) hungarian notation, or other common naming conventions, tend to not like it. The same goes for most of the Unix-heads that I know and have worked with. The ones that were "raised" on it, however, tend to like it. Personally, I can speak from (bad) experience that nothing is worse than having to go through someone else's code who thinks that all variables should start with an "_", and then just have no naming convention whatsoever. Can you tell me anything about the following variables (besides their names)? _Id _RetValue _StatusValue _BookObject What types are they? Pointers? Objects? Basic Types? Member Variables? How about these? m_iId _dwRetValue m_bStatusValue _pBookObject Even without knowing exactly what convention is in use, you know more about these identifiers than you did with the ones above. When dealing with smaller projects, it is not such a big deal. When dealing with megabytes of production-server-quality code, that little bit of knowledge can save LOTS of time (and money). But I agree with the fact that using a naming convention does not make one a great coder. There are still people out there that may know all of the naming conventions, use them all the time, but still do stupid stuff like writing functions that take complex, or memory-intensive objects by value instead of by reference, or taking a _bstr_t as a parameter when a BSTR would do fine (and not require the allocation and deallocation of memory). You have to learn the right thing to do, and then do it. Practice does not make perfect. Practice makes habit (age reference). *Perfect* practice makes perfect. Good coders are concerned about both stability/robustness and speed. Good code is fast. Good code is robust. A few things (most) good coders do (by no means a complete list): o Comment their code *well* o *Always* initialize o *Always* check any pointers before use o *Always* check any return codes/values o Never confuse NULL with NUL o Know when to use a temporary (and when NOT to) o Never use "catch( ... ) { /* Do Nothing */ }" o Know how to read a crash-dump (or at least how to read the registers to know if you dereferenced a NULL, or had garbage data, etc.) o If accepting a poi
