View mode: basic / threaded / horizontal-split · Log in · Help
August 01, 2004
Re: proposal for a standard way to name member function arguments...
"clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
> In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
> >
> >clayasaurus wrote:
> >
> >> hello, I'm having a simple problem. Let's say I have a class
> >>
> >> class Foo
> >> {
> >> int size; // size var
> >>
> >> this(int _size) // size this will set it
> >> {
> >> size = _size; // set size to size
> >> }
> >> }
> >>
> >> the problem is that I have to _size for the function var.
> >> To me this seems messy, I could also use sizevar or some other strange name but
> >> I
> >> feel _size is the closest I could get to size.
> >>
> >> What I wouldn't mind is a standard way to declare, for member functions at
> >> least,
> >> something that would help tell it apart from the class member variables.
> >>
> >> Maybe something like this...
> >>
> >> class Foo
> >> {
> >> int size;
> >>
> >> this(int @size) // the '@' signifies it as a member function argument
> >> {
> >> size = @size; // this way you can tell member vars from function arguments
> >> }
> >>
> >> }
> >>
> >> so does anyone else think something like this would be good?
> >> is there a better solution already available?
> >>
> >>
> >
> >All I have to say, and this is with no great offense intended, is yuck.
> >  I'm not sure if this works in D, and I don't have the time to test it,
> >but you could always try:
> >
> >class Foo
> >{
> > int size; // size var
> >
> > this(int size)
> > {
> > this.size = size;
> > }
> >}
> >or just forget about it entirely.  Especially in that kind of a
> >function, it doesn't matter what you call it, all people care about is
> >that you have a class Foo that has a constructor that takes an integer
> >size.  You could call it this(int max) for all people'd care.
> >
> >Heck, you could do:
> >
> >this(int bazooka) // ctor to set the default size
> >{
> >
> >}
> >
> >if you really wanted.  I don't think it's worthy of adding a new symbol
> >to the lexicon just to distinguish fields from locals.
> >
> >-Deja
>
> I think I'll just use the this.membervar way then. That seems to work.
> thx.

I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then you've
a silent bug.
August 01, 2004
Re: proposal for a standard way to name member function arguments...
Matthew wrote:
> "clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
> 
>>In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
>>>Heck, you could do:
>>>
>>>this(int bazooka) // ctor to set the default size
>>>
>>>if you really wanted.  I don't think it's worthy of adding a new symbol
>>>to the lexicon just to distinguish fields from locals.
>>>
>>>-Deja
>>
>>I think I'll just use the this.membervar way then. That seems to work.
>>thx.
> 
> 
> I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then you've
> a silent bug.

This really is the sort of thing that can bite you later on.

What I typically do is just make the argument name a bit more descriptive:

    class Container {
        this(int initialSize) {
            size = initialSize;
        }
        private int size;
    }

 -- andy
August 01, 2004
Re: proposal for a standard way to name member function arguments...
In article <cehe8e$1h8u$1@digitaldaemon.com>,
"C. Sauls" <ibisbasenji@yahoo.com> wrote:

> me wrote:
> > The @ doesn't read righ if you've ever done any pascal, because @x in pascal
> > is the same as &x in C.

Ok, but there's already an address-of operator.  

> Doesn't read right to anyone familiar with MOO or ColdC either, where @ 
> is used to unbox lists.  Aka, in ColdC I'd do something like:
> 
> 	foo = [1, 2, 3, 4, 5];
> 	.bar(@foo);  // the same as doing: .bar(1, 2, 3, 4, 5)

Since one can overload bar() to take an array, do we really need this?  

Just to add to the whole '@' mix:  it's also been used by various C/C++ 
compilers as a language extension for embedded systems. It allows the 
programmer to specify the address of a variable.

But maybe it will be used for something completely different in D.
August 01, 2004
Hungarian Notation (was ...a standard way to name ... arguments)
In article <ceh35c$1ctn$2@digitaldaemon.com>, Matthew says...

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

This actually /is/ Hungarian notation, or at least part of it, and is
specifically discouraged in the style guide.

What do other people think of this style-guide rule? Do you follow it? Disregard
it? Do you think it's wise? Unwise?

I'll put my cards on the table here. Personally, I can't stand Hungarian
notation. As per Walter's advice, I just say no. However, contrary to Matthew's
claim, my code is not full of hidden bugs (well - not those associated with name
clashes anyway). Maybe it's just what you're used to?

Arcane Jill
August 01, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
Arcane Jill wrote:

> In article <ceh35c$1ctn$2@digitaldaemon.com>, Matthew says...
> 
> 
>>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.
> 
> 
> This actually /is/ Hungarian notation, or at least part of it, and is
> specifically discouraged in the style guide.
> 
> What do other people think of this style-guide rule? Do you follow it? Disregard
> it? Do you think it's wise? Unwise?
> 
> I'll put my cards on the table here. Personally, I can't stand Hungarian
> notation. As per Walter's advice, I just say no. However, contrary to Matthew's
> claim, my code is not full of hidden bugs (well - not those associated with name
> clashes anyway). Maybe it's just what you're used to?
> 
> Arcane Jill
> 
> 

How do you feel about the following variable names?

    real i, j, k;

If I am right that in assuming these name will never have a real 
type in any of your code then I would say that goes to support 
your suggestion that it is what you are used to.
August 01, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
parabolis wrote:

> How do you feel about the following variable names?
> 
>     real i, j, k;
> 
> If I am right that in assuming these name will never have a real type in 
> any of your code then I would say that goes to support your suggestion 
> that it is what you are used to.

class Quaternion {
    real r;
    real i, j, k;
    ...
}

:)

 -- andy
August 01, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
Andy Friesen wrote:
> parabolis wrote:
> 
>> How do you feel about the following variable names?
>>
>>     real i, j, k;
>>
>> If I am right that in assuming these name will never have a real type 
>> in any of your code then I would say that goes to support your 
>> suggestion that it is what you are used to.
> 
> 
> class Quaternion {
>     real r;
>     real i, j, k;
>     ...
> }
> 
> :)
> 
>  -- andy

lol good point.
August 01, 2004
Re: proposal for a standard way to name member function arguments...
In article <cehqdb$1luj$1@digitaldaemon.com>, Andy Friesen says...
>
>Matthew wrote:
>> "clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
>> 
>>>In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
>>>>Heck, you could do:
>>>>
>>>>this(int bazooka) // ctor to set the default size
>>>>
>>>>if you really wanted.  I don't think it's worthy of adding a new symbol
>>>>to the lexicon just to distinguish fields from locals.
>>>>
>>>>-Deja
>>>
>>>I think I'll just use the this.membervar way then. That seems to work.
>>>thx.
>> 
>> 
>> I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then you've
>> a silent bug.
>
>This really is the sort of thing that can bite you later on.
>
>What I typically do is just make the argument name a bit more descriptive:
>
>     class Container {
>         this(int initialSize) {
>             size = initialSize;
>         }
>         private int size;
>     }
>
>  -- andy


Hrm. This will probably fix it. I am torn whether to use a form of hungarian
notation (which is discouraged in the D style guide and means more typing, but
also means that I can tell where the variables belong to), or to just use
different variable names for the same type of variable (size, initsize). 

To me, hungarian notation seems like a fail-safe way to do it, while the other
way is more creative. But then I don't like making up two variable names for the
same thing. 

I think I'm leaning more towards decorating my variables so I know where they
belong and avoid name clashes.
August 01, 2004
Re: proposal for a standard way to name member function arguments...
"clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cej8aa$28c0$1@digitaldaemon.com...
> In article <cehqdb$1luj$1@digitaldaemon.com>, Andy Friesen says...
> >
> >Matthew wrote:
> >> "clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
> >>
> >>>In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
> >>>>Heck, you could do:
> >>>>
> >>>>this(int bazooka) // ctor to set the default size
> >>>>
> >>>>if you really wanted.  I don't think it's worthy of adding a new symbol
> >>>>to the lexicon just to distinguish fields from locals.
> >>>>
> >>>>-Deja
> >>>
> >>>I think I'll just use the this.membervar way then. That seems to work.
> >>>thx.
> >>
> >>
> >> I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then
you've
> >> a silent bug.
> >
> >This really is the sort of thing that can bite you later on.
> >
> >What I typically do is just make the argument name a bit more descriptive:
> >
> >     class Container {
> >         this(int initialSize) {
> >             size = initialSize;
> >         }
> >         private int size;
> >     }
> >
> >  -- andy
>
>
> Hrm. This will probably fix it. I am torn whether to use a form of hungarian
> notation (which is discouraged in the D style guide and means more typing, but
> also means that I can tell where the variables belong to), or to just use
> different variable names for the same type of variable (size, initsize).

It's 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.

>
> To me, hungarian notation seems like a fail-safe way to do it, while the other
> way is more creative. But then I don't like making up two variable names for the
> same thing.
>
> I think I'm leaning more towards decorating my variables so I know where they
> belong and avoid name clashes.
>
>
August 01, 2004
Re: Hungarian Notation (was ...a standard way to name ... arguments)
"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ceivvq$24sp$1@digitaldaemon.com...
> In article <ceh35c$1ctn$2@digitaldaemon.com>, Matthew says...
>
> >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.
>
> This actually /is/ Hungarian notation, or at least part of it, and is
> specifically discouraged in the style guide.

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.


>
> What do other people think of this style-guide rule? Do you follow it? Disregard
> it? Do you think it's wise? Unwise?
>
> I'll put my cards on the table here. Personally, I can't stand Hungarian
> notation. As per Walter's advice, I just say no. However, contrary to Matthew's
> claim, my code is not full of hidden bugs (well - not those associated with name
> clashes anyway). Maybe it's just what you're used to?

Sigh. I made no claims about your code, because I've never seen it.

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.
1 2 3
Top | Discussion index | About this forum | D home