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



 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,


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?

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

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