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/

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

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.

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

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.

"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.

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?