Phango - questions

Bill Baxter dnewsgroup at billbaxter.com
Mon Nov 19 18:35:27 PST 2007


Sean Kelly wrote:
> Bill Baxter wrote:
>>
>> I used to be a big 'm_' guy, but I recently started using trailing 
>> underscores for private members.  Started doing that after porting 
>> OpenMesh from C++, which uses that convention.  I was amazed at how 
>> much more readable all the code looked with the garbage characters 
>> appended as a suffix rather than a prefix.  Apparently this style is 
>> used some by Boost as well as the ACE library.  Trying to find out 
>> where it came from I ran across a quote from someone saying (in 2004) 
>> that it's "the de facto cool kids' C++ style".  :-) 
>> http://discuss.joelonsoftware.com/default.asp?joel.3.49438.14
>>
>> I asked the original OpenMesh devs about it and one responded that he 
>> used to be in typography before computer science, and from what he 
>> learned doing that about how humans read he could say the suffix 
>> version is definitely going to be more readable.
> 
> I prefer the "m_" prefix specifically because it is more visible than a 
> suffix.  Perhaps I simply haven't spent enough time with the suffix 
> form, but I feel that it's easier to miss a trailing underscore.  

That's exactly why it's so great.  It feels like you're using regular 
variables instead of ugly hungarian notation, but you still get the 
benefit of the notation when you're confused or trying to figure out 
what's what in a function.

> I am also not sure of how I would indicate static member data with a 
> suffix... perhaps myVar_M and myVar_SM?

I guess.  I used to do the ms_ for static variables but never found 
myself confused over whether a variable was static or not.  So I dropped 
it.  I guess I just don't use static variables enough or do enough 
multithreaded programming for it to be an important distinction.
If I wasn't clear the convention I was talking about is to use "foo_" 
for private member vars.  So if I wanted to annotate statics, I'd 
probably try "_s".

--bb



More information about the Digitalmars-d mailing list