digitalmars.D.learn - local variable naming convention
- Boyd (17/17) Dec 20 2013 I'm in the process of adapting my library to the D standard
- kdmult (6/13) Dec 20 2013 this(int x, int y)
- bearophile (8/13) Dec 20 2013 In D I prefer:
- Boyd (5/18) Dec 20 2013 I concur. And I should probably get used to using 'this' a lot as
- Jonathan M Davis (9/24) Dec 20 2013 Whereas I put the underscore before (e.g. _x), and some folks like to do...
- Jeremy DeHaan (17/20) Dec 20 2013 I tend to use the m_x naming convention, though I limit it to
- Boyd (10/30) Dec 20 2013 I've never seen the use of "the" before. I must say I like the
- Jacob Carlborg (4/5) Dec 20 2013 "member" I would guess.
- Gary Willoughby (15/28) Dec 20 2013 I tend to use the opposite for private/protected member variables
- Jacob Carlborg (42/56) Dec 20 2013 This is how I would do it:
I'm in the process of adapting my library to the D standard naming convention. The problem is that I used to separate member variables and local variables through capitalization. X would be a member variable. x would be a local variable. this allowed me, among other things, to create constructors such as: this(int x, int y) { X = x; Y = y; } So now my question is, how do you distinguish between member and local vars in such cases? Cheers, Boyd
Dec 20 2013
On Friday, 20 December 2013 at 09:15:26 UTC, Boyd wrote:this(int x, int y) { X = x; Y = y; } So now my question is, how do you distinguish between member and local vars in such cases?this(int x, int y) { this.x = x; this.y = y; }
Dec 20 2013
kdmult:this(int x, int y) { this.x = x; this.y = y; }In D I prefer: this(int x_, int y_) { this.x = x_; this.y = y_; } Bye, bearophile
Dec 20 2013
On Friday, 20 December 2013 at 09:30:08 UTC, bearophile wrote:kdmult:I concur. And I should probably get used to using 'this' a lot as well. Maybe it would be a good idea to add this kind of information to the official coding style guide.this(int x, int y) { this.x = x; this.y = y; }In D I prefer: this(int x_, int y_) { this.x = x_; this.y = y_; } Bye, bearophile
Dec 20 2013
On Friday, December 20, 2013 10:30:06 bearophile wrote:kdmult:Whereas I put the underscore before (e.g. _x), and some folks like to do m_x (though I haven't seen many people do that in D - more in C++). It doesn't really matter. But the typical naming conventions have types being PascalCased, and everything else being camelCased, so naming any variables with PascalCasing (or simply making them all uppercase) is definitely not the typical thing to do in D. http://dlang.org/dstyle.html - Jonathan M Davisthis(int x, int y) { this.x = x; this.y = y; }In D I prefer: this(int x_, int y_) { this.x = x_; this.y = y_; }
Dec 20 2013
On Friday, 20 December 2013 at 10:06:36 UTC, Jonathan M Davis wrote:Whereas I put the underscore before (e.g. _x), and some folks like to do m_x (though I haven't seen many people do that in D - more in C++).I tend to use the m_x naming convention, though I limit it to private member variables. Otherwise I stick to camelCase. If it is a parameter that is just going to be assigned to a member variable and they would otherwise have the same name, I usually add a prefix to parameter name to differentiate the two. In constructors it is usually "the" and in setters it is usually "new." Something like: this(string theTitle) { title = theTitle; } void setTitle(string newTitle) { title = newTitle; }
Dec 20 2013
On Friday, 20 December 2013 at 10:29:26 UTC, Jeremy DeHaan wrote:On Friday, 20 December 2013 at 10:06:36 UTC, Jonathan M Davis wrote:I've never seen the use of "the" before. I must say I like the sound of it better than using 'title_'. I'm not a big fan of arbitrary signs, even though I use '_title' if there is already setter called 'title' For setter parameters I tend to use 'value', though now that might compromise certain cases where 'value' is already a member. I do occasionally use 'new' as well, so I'll probably start using that. What does m_ stand for anyway?Whereas I put the underscore before (e.g. _x), and some folks like to do m_x (though I haven't seen many people do that in D - more in C++).I tend to use the m_x naming convention, though I limit it to private member variables. Otherwise I stick to camelCase. If it is a parameter that is just going to be assigned to a member variable and they would otherwise have the same name, I usually add a prefix to parameter name to differentiate the two. In constructors it is usually "the" and in setters it is usually "new." Something like: this(string theTitle) { title = theTitle; } void setTitle(string newTitle) { title = newTitle; }
Dec 20 2013
On 2013-12-20 12:16, Boyd wrote:What does m_ stand for anyway?"member" I would guess. -- /Jacob Carlborg
Dec 20 2013
On Friday, 20 December 2013 at 09:30:08 UTC, bearophile wrote:kdmult:I tend to use the opposite for private/protected member variables as per the d style guidelines located here: http://dlang.org/dstyle.html. "Unless listed otherwise below, names should be camelCased (this includes all variables). So, names formed by joining multiple words have each word other than the first word capitalized. Also, names do not begin with an underscore ‘_’ unless they are private." Example: this(int x, int y) { this._x = x; this._y = y; }this(int x, int y) { this.x = x; this.y = y; }In D I prefer: this(int x_, int y_) { this.x = x_; this.y = y_; } Bye, bearophile
Dec 20 2013
On 2013-12-20 10:15, Boyd wrote:I'm in the process of adapting my library to the D standard naming convention. The problem is that I used to separate member variables and local variables through capitalization. X would be a member variable. x would be a local variable. this allowed me, among other things, to create constructors such as: this(int x, int y) { X = x; Y = y; } So now my question is, how do you distinguish between member and local vars in such cases?This is how I would do it: class Point { private int x_; private int y_; this (int x, int y) { x_ = x; y_ = y; } int x () { return x_; } int y () { return y_; } int x (int x) { return x_ = x; } int y (int y) { return y_ = y; } } If I don't have a conflict with methods I just drop the underscore and use "this." in the constructor: struct Point { int x; int y; this (int x, int y) { this.x = x; this.y = y; } } -- /Jacob Carlborg
Dec 20 2013