View mode: basic / threaded / horizontal-split · Log in · Help
August 02, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
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
August 02, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
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/
August 03, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
In article <opsb4j7mcf5a2sq9@digitalmars.com>, Regan Heath says...

>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?

According to scoping rules, yes. And it does seem to work that way in practice.

Jill
August 03, 2004
Re: proposal for a standard way to name member function arguments...
Derek <derek@psyc.ward> wrote in 
news:1fyk9zpw8zx89.4hp4g3ij6ps6.dlg@40tude.net:

> For what its worth, for the last many-years now, I've generally been
> prefixing my identifer names with a code that indicates scope and
> static-ness. It doesn't take long to write and makes reading code a lot
> easier.
> 
>  class Foo
>  {
>    private:
>     int cSize; // size var
> 
>    public:
>     this(int piSize) // size this will set it
>     {
>       cSize = piSize; // set size to size
>     }
>  }
> 
> "c" -->  "class" variable
> "pi" --> "parameter in"
> "po" --> "parameter out"
> "pu" --> "parameter i/o"
> "g"  --> "global" / public
> "k"  --> "constant" / "static"
> "l"  --> "local" to routine
> "m"  --> scoped to module
> 
> Well it works for me; YMMV
> 

Hi Derek,

I'm not exactly sure how pi, po and pu should be used.

Could you please enlighten me about how to prefix 'val' for the following 
cases. I assume you've been using your prefix system with C++, so I use C++ 
here, too.

1. foo(const Vector<int>& val) 
piVal

2. foo(Vector<int>& val) // changes elements of the vector
puVal

3. foo(Vector<int>& val) // adds elements to the vector
puVal

4. foo(Vector<int>** val) // returns a new vector 
poVal


Did I mis-guess anything?


Farmer.
August 03, 2004
Re: proposal for a standard way to name member function arguments...
On Tue, 3 Aug 2004 20:32:50 +0000 (UTC), Farmer wrote:

> Derek <derek@psyc.ward> wrote in 
> news:1fyk9zpw8zx89.4hp4g3ij6ps6.dlg@40tude.net:
> 
>> For what its worth, for the last many-years now, I've generally been
>> prefixing my identifer names with a code that indicates scope and
>> static-ness. It doesn't take long to write and makes reading code a lot
>> easier.
>> 
>>  class Foo
>>  {
>>    private:
>>     int cSize; // size var
>> 
>>    public:
>>     this(int piSize) // size this will set it
>>     {
>>       cSize = piSize; // set size to size
>>     }
>>  }
>> 
>> "c" -->  "class" variable
>> "pi" --> "parameter in"
>> "po" --> "parameter out"
>> "pu" --> "parameter i/o"
>> "g"  --> "global" / public
>> "k"  --> "constant" / "static"
>> "l"  --> "local" to routine
>> "m"  --> scoped to module
>> 
>> Well it works for me; YMMV
>> 
> 
> Hi Derek,
> 
> I'm not exactly sure how pi, po and pu should be used.
> 
> Could you please enlighten me about how to prefix 'val' for the following 
> cases. I assume you've been using your prefix system with C++, so I use C++ 
> here, too.
> 
> 1. foo(const Vector<int>& val) 
> piVal
> 
> 2. foo(Vector<int>& val) // changes elements of the vector
> puVal
> 
> 3. foo(Vector<int>& val) // adds elements to the vector
> puVal
> 
> 4. foo(Vector<int>** val) // returns a new vector 
> poVal
> 
> 
> Did I mis-guess anything?

Yes. I don't use C++ (or Java or C#). Most of my programming has been done
using the 4GL called 'Progress', though C, VB, Euphoria, COBOL, Pascal, and
Assembler(IBM, Motorola, Intel) have been used too.

-- 
Derek
Melbourne, Australia
August 04, 2004
Re: proposal for a standard way to name member function arguments...
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.


Farmer wrote:
> Derek <derek@psyc.ward> wrote in 
> news:1fyk9zpw8zx89.4hp4g3ij6ps6.dlg@40tude.net:
> 
> 
>>For what its worth, for the last many-years now, I've generally been
>>prefixing my identifer names with a code that indicates scope and
>>static-ness. It doesn't take long to write and makes reading code a lot
>>easier.
>>
>> class Foo
>> {
>>   private:
>>    int cSize; // size var
>>
>>   public:
>>    this(int piSize) // size this will set it
>>    {
>>      cSize = piSize; // set size to size
>>    }
>> }
>>
>>"c" -->  "class" variable
>>"pi" --> "parameter in"
>>"po" --> "parameter out"
>>"pu" --> "parameter i/o"
>>"g"  --> "global" / public
>>"k"  --> "constant" / "static"
>>"l"  --> "local" to routine
>>"m"  --> scoped to module
>>
>>Well it works for me; YMMV
>>
> 
> 
> Hi Derek,
> 
> I'm not exactly sure how pi, po and pu should be used.
> 
> Could you please enlighten me about how to prefix 'val' for the following 
> cases. I assume you've been using your prefix system with C++, so I use C++ 
> here, too.
> 
> 1. foo(const Vector<int>& val) 
> piVal
> 
> 2. foo(Vector<int>& val) // changes elements of the vector
> puVal
> 
> 3. foo(Vector<int>& val) // adds elements to the vector
> puVal
> 
> 4. foo(Vector<int>** val) // returns a new vector 
> poVal
> 
> 
> Did I mis-guess anything?
> 
> 
> Farmer.
August 04, 2004
Re: proposal for a standard way to name member function arguments...
"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.
August 04, 2004
Re: proposal for a standard way to name member function arguments...
Derek <derek@psyc.ward> wrote in
news:1ngq3pbtpbs9l.f4mzhcpm0rt0.dlg@40tude.net: 

> On Tue, 3 Aug 2004 20:32:50 +0000 (UTC), Farmer wrote:
[snip]
>> Did I mis-guess anything?
> 
> Yes. I don't use C++ (or Java or C#). Most of my programming has been
> done using the 4GL called 'Progress', though C, VB, Euphoria, COBOL,
> Pascal, and Assembler(IBM, Motorola, Intel) have been used too.
> 

Fine list of progamming languages, let me choose C

1. foo(int val[]) // accesses elements of the array
piVal

2. foo(int val[]) // changes elements of the array
puVal

3. foo(int** val) // adds elements to the array (array is reallocated)
puVal

4. foo(int** val) // returns a new array 
poVal


Did I mis-guess anything?
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home