Thread overview
local variable naming convention
Dec 20, 2013
Boyd
Dec 20, 2013
kdmult
Dec 20, 2013
bearophile
Dec 20, 2013
Boyd
Dec 20, 2013
Jonathan M Davis
Dec 20, 2013
Jeremy DeHaan
Dec 20, 2013
Boyd
Dec 20, 2013
Jacob Carlborg
Dec 20, 2013
Gary Willoughby
Dec 20, 2013
Jacob Carlborg
December 20, 2013
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
December 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;
}
December 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
December 20, 2013
On Friday, 20 December 2013 at 09:30:08 UTC, bearophile wrote:
> 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

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.
December 20, 2013
On Friday, December 20, 2013 10:30:06 bearophile wrote:
> 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_;
> }

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 Davis
December 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;
}
December 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:
>> 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;
> }

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?
December 20, 2013
On Friday, 20 December 2013 at 09:30:08 UTC, bearophile wrote:
> 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

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;
}
December 20, 2013
On 2013-12-20 12:16, Boyd wrote:

> What does m_ stand for anyway?

"member" I would guess.

-- 
/Jacob Carlborg
December 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