www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - proposal for a standard way to name member function arguments...

reply clayasaurus <clayasaurus_member pathlink.com> writes:
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?
Jul 31 2004
next sibling parent reply h3r3tic <h3r3tic dev.null> writes:
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. 


How about just using m_size for member vars. I think it's quite a 
standard naming convention...



 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? 


If we were to go that way somehow,   should be used for member vars, not 
for params. It's how Ruby does it, so some ppl would already be familiar 
with that thing.
Jul 31 2004
parent reply "me" <memsom interalpha.co.uk> writes:
 How about just using m_size for member vars. I think it's quite a
 standard naming convention...


fSize would be my vote. f as in field. Field being a proper OO term along
with attribute and operation.

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

Matt
Jul 31 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
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.


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)

-Chris S.
-Invironz
Jul 31 2004
parent James Widman <james jwidman.com> writes:
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.
Jul 31 2004
prev sibling next sibling parent reply Deja Augustine <deja scratch-ware.net> writes:
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
Jul 31 2004
parent reply clayasaurus <clayasaurus_member pathlink.com> writes:
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.
Jul 31 2004
next sibling parent h3r3tic <h3r3tic dev.null> writes:
clayasaurus wrote:


class Foo
{
	int size; // size var

	this(int size)
	{
		this.size = size;
	}
}


 
 I think I'll just use the this.membervar way then. That seems to work. 
 thx. 
 
 



K, this seems nice, just don't use the 'size' name or you'll have 
problems :)
Jul 31 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Jul 31 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Jul 31 2004
parent reply clayasaurus <clayasaurus_member pathlink.com> writes:
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.
Aug 01 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Aug 01 2004
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Simple, decorate your member variables.

I use m_ (instance / non-static) and sm_ (class / static).  This is what DTL
(and STLSoft) uses.

Other schemes are using a _ postfix, which is ok, but less good.

A bad one is using a _ prefix, since that breeds this bad habit elsewhere, and
some languages (including D, in some
respects, I think) reserve this for the implementation (i.e. the compiler
vendor and/or the standard)

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.

(Interestingly - and Yes! he's plugging again - I'm working through the final
layout proofs of Imperfect C++ at the
moment, and have just covered this in chapter 17 - Syntax. Honesty compels me
to recommend you pre-order this gem, due
out Sept 9th. <G>)



"clayasaurus" <clayasaurus_member pathlink.com> wrote in message
news:cegc93$139u$1 digitaldaemon.com...

 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?
Jul 31 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Aug 01 2004
next sibling parent reply parabolis <parabolis softhome.net> writes:
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.
Aug 01 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Aug 01 2004
parent parabolis <parabolis softhome.net> writes:
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.
Aug 01 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Aug 01 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Aug 02 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Aug 02 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
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
Aug 03 2004
prev sibling next sibling parent reply Derek <derek psyc.ward> writes:
On Sat, 31 Jul 2004 15:01:55 +0000 (UTC), 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?


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

-- 
Derek
Melbourne, Australia
Jul 31 2004
parent reply Farmer <itsFarmer. freenet.de> writes:
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.
Aug 03 2004
next sibling parent reply Derek <derek psyc.ward> writes:
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?



using the 4GL called 'Progress', though C, VB, Euphoria, COBOL, Pascal, and
Assembler(IBM, Motorola, Intel) have been used too.

-- 
Derek
Melbourne, Australia
Aug 03 2004
parent Farmer <itsFarmer. freenet.de> writes:
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?


 

 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?
Aug 04 2004
prev sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
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.
Aug 03 2004
parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
"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.
Aug 04 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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? 
  


I just use lower case (first letter) for parameters and upper for members.


-- 
-Anderson: http://badmama.com.au/~anderson/
Jul 31 2004