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_
#{
# private:
#//  char[] first; can't use ... conflicts with property 'getter'
#  char[] m_first;
#  char[] m_last;
#
#  public:
#  this(char[] first, char[] last) {
#    m_first = first;
#    m_last  = last;
#  }
#  char[] first() { return m_first; }
#  char[] last()  { return m_last; }
#}
#
#class NameWithAbbrev
#{
# private:
#  char[] f;
#  char[] l;

#  public:
#  this(char[] first, char[] last) {
#    f = first;
#    l = last;
#  }
#  char[] first() { return f; }
#  char[] last()  { return l; }
#}

#class NameWithGetSet
#{
# private:
#  char[] first;
#  char[] last;

#  public:
#  this(char[] first, char[] last) {
#    this.first = first;
#    this.last = last;
#  }
#  char[] getFirst() { return first; }
#  char[] getLast()  { return last; }
#}

#void main()
#{
#  NameWith_M_ joe = new NameWith_M_("Joe", "Johnson");
#  writefln("Joe's first name is ", joe.first);
#
#  NameWithAbbrev jane = new NameWithAbbrev("Jane", "Jones");
#  writefln("Jane's first name is ", jane.first);

#
#  NameWithGetSet walter = new NameWithAbbrev("Walter", "Bright");
#  writefln("Walter's last name is ", walter.getLast);
#}

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.

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 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
 
 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 { # char[] foo; # property set foo(char [] v) { # foo = v; # } # # property get foo() { # return foo; # } #} (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) { # /* do something bar with v, then */ # foo = 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 { # property char[] foo; #} 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) { # /* do something bar with v, then */ # foo = 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 { # char[] foo; # property set foo(char [] v) { # foo = v; # } # # property get foo() { # return foo; # } #} (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) { # /* do something bar with v, then */ # foo = 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 { # property char[] foo; #} 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) { # /* do something bar with v, then */ # foo = 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) I seem to remember the C# syntax for properties being a lot cleaner... 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