Julian Gonggrijp wrote:
All this talking of underscores makes me wonder about private class members. Several authors advise to give them names with a prefix underscore (followed by a lowercase letter). It does seem to have clear advantages: it visually marks the members as implementation details, and it also makes it easier to distinguish class member data from arguments and locally declared variables in member functions.
However, your opinions probably differ wildly on the matter. Would you consider it good practice to give private class members a name that starts with _[a-z] (regex)?
Distinguishing private data members from local variables and formal parameters is useful. It creates a distinct "namespace" from local variable and formal parameter names. How to mark them is purely subjective. Some use the "m_" prefix, popularized by MFC and MSVC code generators, but I find that to be too much of a wart on the name. Some use "this->" as a prefix, so their data member names need no special marking. I like to distinguish protected and private data members but with a trailing underscore. I use a trailing underscore because it is less important than the data member's name. (I also use a preceding underscore for formal parameters to give them another "namespace." In that case, the underscore can't be on the end, of course.) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.