Re: Microsoft style:
"Joseph M. Newcomer" wrote in message
news:am6cp6h7bg4d7gn8rd7id64smq62lbgr5c@4ax.com...
All very well till you accidentally define a local variable called 'date'
in
a member function.
****
This is not possibly a problem
typedef struct {
DWORD date;
} THING;
void SomeFunc(THING & t)
{
DWORD date;
date = t.date;
...do stuff to date variable
t.date = date;
}
Note that I had exactly *one* abstraction here, "date", which is referred to
by the name
"date" everywhere it is used.
----
Yes I can do that too, but I prefer not to as different names are clearer.
----
You can argue that m_date for a member variable makes sense so you can write
void THING::SetDate(DWORD date)
{
m_date = date;
}
but that is a consistent concept if you use it correctly. But writing
thng_date = date;
in one piece of code and
whatever_date = date;
for another class makes no sense.
-----
Well if they're that strongly related, you can derive one from the other and
there's then only one. And if they're not, then I don't mind them having
different names. One is the 'date of the thing' the other the 'date of the
whatever'.
-----
Particularly if there are weird abbreviations like
thng_date = date;
wht_date = date;
then the weird abbreviations add one more level of complexity to the
understanding,
-----
Where it isn't obvious I have even been known to write THING::thng_date
within a member function of THING :-)
These days I don't do it often, as it usually points to the idea that a
clearer nomenclature would be better.
----
whereas
m_date = date;
has a single, uniform concept everywhere.<
----
I guesss m_ means member. My system just makes a bit more information
explicit - what it's a member of.
I still use m_ for members of CDialog-derived classes though: just out of
bad habit acquired from Microsoft :-)
----
It's the same reason we have function overloading so we can have
void DoSomething(char *);
void DoSomething(int);
void DoSomething(double);<
----
Well that's slightly different (and I do it a lot). These are members of
the same class - my different prefixes distinguish members of different
classes.
----
[Note that the insanity where some APIs are using "Rgn" and some APIs are
using "Region"
is also avoided; is it "Double" or "Dbl"?]
---
Yes I try to avoid that as it makes searching for things easier if you're
consistent.
More later.
Dave
-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm