www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Naming conventions for properties and member variables?

reply "Lynn Allan" <l_d_allan adelphia.net> writes:
Sorry if this has been resolved or is in the status of "agree to
disagree" after being "gummed to death". <g>

Has a naming convention emerged for naming member variables and their
corresponding properties? I've seen a variety of styles in the
documentation, in phobos, and in other contributed library codes. I'd
prefer to utilize a standard/convention in my own code, as
appropriate.

If I understand the issue, the most natural naming for a "property
getter/setter" isn't allowed because of compiler name conflicts:
class Name {
  char[] first;  // compiler complains
  ...
  char[] first { return first; }
}

Other alternatives require that the member variable name and the
getter/setter be different. I've seen the use of m_ ,abbreviations for
the private member variable, and getFirst and setFirst.

Is there a consensus / preference that has emerged? Am I confused?

For example, for a very simple class such as Name:
#import std.stdio;

#class NameWith_M_















#class NameWithAbbrev














#class NameWithGetSet














#void main()












I would think the first priority is clarity to the "user" of the class
(including the documented signatures for the class methods) , and the
second is readability to the developer.

Personally, I prefer m_first to clarify that a class member variable
is being used within the actual class code, and preserving the most
natural naming for the user of the class.

Other thoughts appreciated.
Dec 24 2004
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Lynn Allan wrote:

 Sorry if this has been resolved or is in the status of "agree to
 disagree" after being "gummed to death". <g>
 
 Has a naming convention emerged for naming member variables and their
 corresponding properties? I've seen a variety of styles in the
 documentation, in phobos, and in other contributed library codes. I'd
 prefer to utilize a standard/convention in my own code, as
 appropriate.


<snip>

If class users aren't going to manipulate the member variable, it 
doesn't matter that much what you call it.  But yes, a convention is useful.

Since this thread cropped up a while back

http://www.digitalmars.com/drn-bin/wwwnews?D/28791

I've pretty much taken to prefixing internal-use member variables with 
an underscore.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
on the 'group where everyone may benefit.
Dec 24 2004
parent reply John Reimer <brk_6502 yahoo.com> writes:
On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:

 
 If class users aren't going to manipulate the member variable, it 
 doesn't matter that much what you call it.  But yes, a convention is useful.
 
 Since this thread cropped up a while back
 
 http://www.digitalmars.com/drn-bin/wwwnews?D/28791
 
 I've pretty much taken to prefixing internal-use member variables with 
 an underscore.
 
 Stewart.


I've never liked the m_ prefix.  It just looks ugly to me and reminds me
too much of popular C++ convention. But the idea of just prefixing
member variables with an underscore doesn't sound that bad.

- John R
Dec 24 2004
parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
John Reimer wrote:

 On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:
  
 I've never liked the m_ prefix.  It just looks ugly to me and reminds me
 too much of popular C++ convention. But the idea of just prefixing
 member variables with an underscore doesn't sound that bad.
 
 - John R
 


I am against both using m_ as well as using _. It makes code lesser 
readable as code which doesn't define names as such.

I never liked the property-is-method idea, I like a more direct property 
approach in general (as done in .NET and, with some imagination, in 
JavaBeans).

I'd like the following much better:

class XYZ {
	property set char[] var {
		self = value;
	}

	property get char[] var {
		return self;
	}
}

Explanation:

property defines a programmed attribute to a class (or struct). set/get 
define whether a property is a set or get method. When having both 
enabled, the "self" member of "property set" sets the value, the "self" 
member of "property get" retrieves the value.

If that is not possible (which is reasonable because the language needs 
to undergo a big change), the pure JavaBeans idea is also good to me 
(using setter/getter methods).

class XYZ {
	char s[];

	void setVar(char[] s) {
		this.s = s;
	}

	char[] getVar() {
		return this.s;
	}
}

But again, it needs a change in how the language works, because this 
time, you need to be able to call var() on an object instantiation and 
this actually calls setVar(..) and/or getVar() in the class.

Regards,
Sjoerd
Dec 24 2004
next sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <cqi3bb$qgj$1 digitaldaemon.com>, Sjoerd van Leent says...

John Reimer wrote:

 On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:
  
 I've never liked the m_ prefix.  It just looks ugly to me and reminds me
 too much of popular C++ convention. But the idea of just prefixing
 member variables with an underscore doesn't sound that bad.
 
 - John R
 


I am against both using m_ as well as using _. It makes code lesser 
readable as code which doesn't define names as such.

I never liked the property-is-method idea, I like a more direct property 
approach in general (as done in .NET and, with some imagination, in 
JavaBeans).

I'd like the following much better:

class XYZ {
	property set char[] var {
		self = value;
	}

	property get char[] var {
		return self;
	}
}

Explanation:

property defines a programmed attribute to a class (or struct). set/get 
define whether a property is a set or get method. When having both 
enabled, the "self" member of "property set" sets the value, the "self" 
member of "property get" retrieves the value.

If that is not possible (which is reasonable because the language needs 
to undergo a big change), the pure JavaBeans idea is also good to me 
(using setter/getter methods).

class XYZ {
	char s[];

	void setVar(char[] s) {
		this.s = s;
	}

	char[] getVar() {
		return this.s;
	}
}

But again, it needs a change in how the language works, because this 
time, you need to be able to call var() on an object instantiation and 
this actually calls setVar(..) and/or getVar() in the class.

Regards,
Sjoerd



Sorry to post without research (hey, it's Christmas Eve around here).

Since a class probably has several "properties", the method names 
should include the propety name.

Personally I'd find it convenient if you could have a class like:

#class XYZ {










(Here, if a variable is not explicitly otherwise declared, it 
is private. And a property is implicitly public.)

And of course, overloading would be allowed, so I could write


#property set foo(int bar, char[] v) {





--- Just my .02€

And this would be used like

XYZ.foo = "yippee";
s = XYZ.foo;

and (for the non-default case):

XYZ.foo(3,"yippee");
s = XYZ.foo;

This could be further automated, and then I could write a class like:

#class XYZ {



and the get and set methods would be generated -- unless I override
them explicitly. So, all I'd have to write explicitly would be the
non-default setter, like:

#property set foo(int bar, char[] v) {




georg

ps, still Christmas Eve here....
Dec 24 2004
parent "Simon Buchan" <currently no.where> writes:
On Sat, 25 Dec 2004 02:06:10 +0000 (UTC), Georg Wrede  
<Georg_member pathlink.com> wrote:


 In article <cqi3bb$qgj$1 digitaldaemon.com>, Sjoerd van Leent says...

 John Reimer wrote:

 On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:

 I've never liked the m_ prefix.  It just looks ugly to me and reminds  
 me
 too much of popular C++ convention. But the idea of just prefixing
 member variables with an underscore doesn't sound that bad.

 - John R


 I am against both using m_ as well as using _. It makes code lesser
 readable as code which doesn't define names as such.

 I never liked the property-is-method idea, I like a more direct property
 approach in general (as done in .NET and, with some imagination, in
 JavaBeans).

 I'd like the following much better:

 class XYZ {
 	property set char[] var {
 		self = value;
 	}

 	property get char[] var {
 		return self;
 	}
 }

 Explanation:

 property defines a programmed attribute to a class (or struct). set/get
 define whether a property is a set or get method. When having both
 enabled, the "self" member of "property set" sets the value, the "self"
 member of "property get" retrieves the value.

 If that is not possible (which is reasonable because the language needs
 to undergo a big change), the pure JavaBeans idea is also good to me
 (using setter/getter methods).

 class XYZ {
 	char s[];

 	void setVar(char[] s) {
 		this.s = s;
 	}

 	char[] getVar() {
 		return this.s;
 	}
 }

 But again, it needs a change in how the language works, because this
 time, you need to be able to call var() on an object instantiation and
 this actually calls setVar(..) and/or getVar() in the class.

 Regards,
 Sjoerd



 Sorry to post without research (hey, it's Christmas Eve around here).

 Since a class probably has several "properties", the method names
 should include the propety name.

 Personally I'd find it convenient if you could have a class like:

 #class XYZ {










 (Here, if a variable is not explicitly otherwise declared, it
 is private. And a property is implicitly public.)

 And of course, overloading would be allowed, so I could write


 #property set foo(int bar, char[] v) {





 --- Just my .02€

 And this would be used like

 XYZ.foo = "yippee";
 s = XYZ.foo;

 and (for the non-default case):

 XYZ.foo(3,"yippee");
 s = XYZ.foo;

 This could be further automated, and then I could write a class like:

 #class XYZ {



 and the get and set methods would be generated -- unless I override
 them explicitly. So, all I'd have to write explicitly would be the
 non-default setter, like:

 #property set foo(int bar, char[] v) {




 georg

 ps, still Christmas Eve here....


Personely, I don't like the idea of auto get/set methods being made,
unless of course, it's only if you don't define anything. But then
why is it a property? (Think write-only var's)


oh well. Chalk it up to bad memory. (something like
<code>
uint x
set(uint in) {x = in}
get {return x}

Foo y // read only
get {return y.bar}
</code>
but that may be too ambiguous)

Hey! Brain blast! (forgive the cheesy expression) What about non-class
properties? (For really specific typedefs)

-- 
"Unhappy Microsoft customers have a funny way of becoming Linux,
Salesforce.com and Oracle customers." - www.microsoft-watch.com:
"The Year in Review: Microsoft Opens Up"
--
"I plan on at least one critical patch every month, and I haven't been  
disappointed."
- Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP
(Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp)
--
"It's been a challenge to "reteach or retrain" Web users to pay for  
content, said Pizey"
-Wired website: "The Incredible Shrinking Comic"
Dec 24 2004
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Sjoerd van Leent wrote:


 If that is not possible (which is reasonable because the language needs 
 to undergo a big change), the pure JavaBeans idea is also good to me 
 (using setter/getter methods).
 
 class XYZ {
     char s[];
 
     void setVar(char[] s) {
         this.s = s;
     }
 
     char[] getVar() {
         return this.s;
     }
 }
 
 But again, it needs a change in how the language works, because this 
 time, you need to be able to call var() on an object instantiation and 
 this actually calls setVar(..) and/or getVar() in the class.


In a way it already does this - just with a different naming convention?

You can start out with a simple member field (not more than a struct):


 class Class
 {
   int member = 0;
 }


And then if you later discover it needs more encapsulation, you can do:


 class Class
 {
   public:
     void member(int member) { _member = member; }
     int member() { return _member; }
   private:
     int _member = 0;
 }


The beauty of this naming, as Thomas mentioned, is the simple syntax:


   Class c = new Class();
 
   c.member = 42;
   writefln("C is %d", c.member);


And that doesn't change between the simple "struct" and the full class ?
Without requiring code to be generated, or extra method call wrappers...

See also: http://www.digitalmars.com/d/cpptod.html#properties
Walter uses a "my" prefix, instead of the above underscore "_"


And like Steward Gordon said:

 If class users aren't going to manipulate the member variable,
 it doesn't matter that much what you call it.


It's more like a local variable ? (the underscore works for me)

--anders
Dec 25 2004
prev sibling parent "Thomas Kuehne" <thomas-dloop kuehne.cn> writes:
"Lynn Allan" <l_d_allan adelphia.net> schrieb im Newsbeitrag
news:cqhhlo$6nm$1 digitaldaemon.com...

 Has a naming convention emerged for naming member variables and their
 corresponding properties? I've seen a variety of styles in the
 documentation, in phobos, and in other contributed library codes. I'd
 prefer to utilize a standard/convention in my own code, as
 appropriate.

 If I understand the issue, the most natural naming for a "property
 getter/setter" isn't allowed because of compiler name conflicts:
 class Name {
   char[] first;  // compiler complains
   ...
   char[] first { return first; }
 }

 Other alternatives require that the member variable name and the
 getter/setter be different. I've seen the use of m_ ,abbreviations for
 the private member variable, and getFirst and setFirst.


The setFirst - getFirst is commonly used in the Java world.
I recommend against using this convention.

reason:
D's hides if it is a getter/setter call or direct access.
This can be of great use during debugging and refactoring.

Thomas
Dec 24 2004