In article <cejlns$2d7t$3@digitaldaemon.com>, Matthew says...
>This is not Hungarian. That was about decorating with type, which is a very bad idea. This would be decorating with
>purpose, which is a very good idea.
Looks like we're both right. :) I looked up Hungarian Notation on Wikipedia. It
says HN was invented for C (which of course doesn't /have/ member variables),
but that HN is sometimes extended to C++ with "m_", "g_" prefixes, etc.. I
assumed that the "m_" thing was part of HN. Looks like the web says sometimes it
is, sometimes it isn't, depending on whom you ask. But yes, you're right in that
"m_" was not part of the original definition.
Well, I guess I partly agree with you. I do use "g_" for global variables, but
mostly that's to discourage myself from using global variables! I don't use "m_"
because I happen to think it looks ugly. That's just an opinion, but I hate to
see chains of "m_"-decorated variable names, like: m_a.m_b.m_c.m_d. To me,
a.b.c.d is just so much nicer. I never have a clash between function parameter
names and member variable names, because I just name them differently, and I
don't get confused about such because the number of parameters passed to a
function is generally very small, so there's not much to keep track of.
In an OO paradigm, /most/ variables are member variables; a /few/ variables are
function parameters, and only a tiny, tiny minority of variables are global
variables. Where I add decoration at all, I add it to the least common case.
I think my biggest problem with HN is that it is a commenting technique - and
comments lie. My /previous/ employer (not my current employer) once gave me code
to work on in which a whole bunch of /global/ variables had an "m_" prefix. When
I asked if I could change their names, my ex-company were reluctant, because too
much else depended on them, and something might break, and didn't see the
problem anyway. That's an extreme example, of course, but it's not unusual to
see wrong variable-name-type-prefixes in code.
But anyway, we do seem to be largely in agreement, apart from the m_ thing,
which is nice.
>Sigh. I made no claims about your code, because I've never seen it.
Agreed. Actually, your claim was generic. You said, and I quote: "The worst of
the lot is to have no decoration, since any reader of your code cannot
immediately see what are member variables and what are local and/or
module/namespace/global variables (for which s_ or g_ can be used). Furthermore,
if you forget the this. in member initialisation, your code will have hidden
bugs. Very poor."
Basically I misread you (my apologies). I read it as "If you have no decoration
.. your code will have hidden bugs". But of course, that's not actually what
you said, so I withdraw my response.
>But if you have things like the following:
>
> class Thing
> {
> this(int value)
> {
> this.value = value;
> }
>
>then your code will be more prone to maintenance errors than
>
> class Thing
> {
> this(int value)
> {
> m_value = value;
> }
>
>
>If that's not obvious to you, then there's nothing more I can say.
Well.... You argue that one might "forget the this." (leading to bugs). Well
yes, one might. But equally, one might "forget the m_" (leading to exactly the
same bug). I see no difference. Unless you're saying that forgetting "this." is
more likely than forgetting "m_", but I don't see why that should be true. Seems
to me that whatever you're most used to is least likely to lead to such
mistakes, and the "this." technique is standard practice in Java, so a lot of
Java people are going to be very used to it indeed.
Anyway, since I personally don't use either technique, I'm not bothered. Me, I
just make sure the variables have different names and the problem doesn't arise.
Jill

On Mon, 2 Aug 2004 07:21:41 +0000 (UTC), Arcane Jill
<Arcane_member@pathlink.com> wrote:
<snip>
> In an OO paradigm, /most/ variables are member variables; a /few/
> variables are
> function parameters, and only a tiny, tiny minority of variables are
> global
> variables. Where I add decoration at all, I add it to the least common
> case.
<snip>
> Me, I
> just make sure the variables have different names and the problem
> doesn't arise.
So, given you tend to rename the least common case, you would do this...
class Foo {
int Value;
void fooBar(int newValue) {
Value = newValue;
}
}
IOW you rename to 'int newValue' as it's only used for this one member
function, whereas the member 'int Value' is possibly/probably used in more
places.
I like it..
- There is no 'm_' or 'this.' to forget.
- The new name is actually more descriptive in this case.
What happens if the class changes to:
class Foo {
int Value;
int newValue;
void fooBar(int newValue) {
Value = newValue;
}
}
I assume the newValue param in fooBar is (still) used and not the member
variable?
Regan.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Daniel Horn" <hellcatv@hotmail.com> wrote in message
news:cepeq9$1qee$1@digitaldaemon.com...
> They should make editors (eg eclipse or something) that append the
> hungarian notation for users who like that. anything not autogenerated
> is subject to mistakes.
If it can be generated it need not ever be part of the serialization, it can
be inserted as a graphic on screen during the editing phase. Then people who
don't like the notation don't need to see it but can still configure what
hints the editor should show and how it should show it. Its analogue to
syntax coloring.
I've used $ in the past for member variables because it makes interpretation
of the source faster, but that's it. But one allready needs such a symbol
(e.g. _) to distinguish get/set functions from variables.
If the source code could become more independent of the individual
preferences of programmers, it would be a good thing (in my humble
oppinion.) Let hungarian notation be a parameterization (/configuration) of
the editor.