Is there a common(-ish) naming style for D?

- camel case or underscores within words of names?

- type names begin with capital?

- underscore before or after member names?

- enum values lowercase?

- constant names?

- etc.? :)

Do you have a document that you would like to share?

Thank you,
Ali

On Fri, Sep 4, 2009 at 8:42 PM, Ali Cehreli<acehreli@yahoo.com> wrote:
> Is there a common(-ish) naming style for D?
>
> - camel case or underscores within words of names?
>
> - type names begin with capital?
>
> - underscore before or after member names?
>
> - enum values lowercase?
>
> - constant names?
>
> - etc.? :)
>
> Do you have a document that you would like to share?

There is a "D style guide" in the D spec that briefly mentions naming conventions, but I'm not sure how many people use it / are aware of its existence.

Most D libraries seem to use camel casing for multi-word names, start types with a capital, start functions/methods with lowercase, and don't put braces on the same line as code. Beyond that, there's a lot of variation. Sometimes enums have ALL_CAPS members, sometimes CamelCased, sometimes lowercased, sometimes even varied within the same library. Constant names are similarly varied. Many people don't indicate class members with any kind of decoration, which .. really irks me ;) but those that do, I've seen _foo, foo_, m_foo, mFoo, and some others.

Personally? I hate underscores and use any naming scheme that doesn't use them. I name all types and constants with CapitalNames and members with mFoo.

Thank you!

Jarrett Billingsley Wrote:
> Many people don't indicate class members with any kind of decoration

I noticed that too. :)

The justification that I've come up with is that, we need the decoration in e.g. C++, because the member declaration is not visible in the implementation file, so the decoration communicates that the member is in the header file.

That's not the case in D, so there is no need for the decoration; but I miss them too. :)

Ali

On Fri, Sep 4, 2009 at 9:18 PM, Ali Cehreli<acehreli@yahoo.com> wrote:
> Thank you!
>
> Jarrett Billingsley Wrote:
>> Many people don't indicate class members with any kind of decoration
>
> I noticed that too. :)
>
> The justification that I've come up with is that, we need the decoration in e.g. C++, because the member declaration is not visible in the implementation file, so the decoration communicates that the member is in the header file.
>
> That's not the case in D, so there is no need for the decoration; but I miss them too. :)

I'm consistently confused by D (and Java and C#) code that doesn't indicate member names, especially when they're named really common things that often conflict with local variables, like "len" or "src" or such. Unless the type is small enough to fit on a single screen, it's easy to forget the member names.

Jarrett Billingsley:
> I'm consistently confused by D (and Java and C#) code that doesn't indicate member names, especially when they're named really common things that often conflict with local variables, like "len" or "src" or such. Unless the type is small enough to fit on a single screen, it's easy to forget the member names.

I usually follow Python usage, and use this.fieldName. Is this bad practice in D?

Bye,
bearophile

On Fri, Sep 4, 2009 at 10:14 PM, bearophile<bearophileHUGS@lycos.com> wrote:
> Jarrett Billingsley:
>> I'm consistently confused by D (and Java and C#) code that doesn't indicate member names, especially when they're named really common things that often conflict with local variables, like "len" or "src" or such. Unless the type is small enough to fit on a single screen, it's easy to forget the member names.
>
> I usually follow Python usage, and use this.fieldName. Is this bad practice in D?

It's not bad practice, but it's somewhat unusual for a C-style language, and not enforced by the language, so it's more likely that people won't follow it.

Jarrett Billingsley wrote:
> On Fri, Sep 4, 2009 at 9:18 PM, Ali Cehreli<acehreli@yahoo.com> wrote:
>> Thank you!
>>
>> Jarrett Billingsley Wrote:
>>> Many people don't indicate class members with any kind of decoration
>> I noticed that too. :)
>>
>> The justification that I've come up with is that, we need the decoration in e.g. C++, because the member declaration is not visible in the implementation file, so the decoration communicates that the member is in the header file.
>>
>> That's not the case in D, so there is no need for the decoration; but I miss them too. :)
> 
> I'm consistently confused by D (and Java and C#) code that doesn't
> indicate member names, especially when they're named really common
> things that often conflict with local variables, like "len" or "src"
> or such. Unless the type is small enough to fit on a single screen,
> it's easy to forget the member names.

Most of the code I write uses classes that fit in one screen (20 lines or so) and still prefixes private fields with an underscore. It's convenient when initializing fields from constructor parameters.

On 2009-09-04 21:07:01 -0400, Jarrett Billingsley <jarrett.billingsley@gmail.com> said:

> On Fri, Sep 4, 2009 at 8:42 PM, Ali Cehreli<acehreli@yahoo.com> wrote:
>> Is there a common(-ish) naming style for D?
>> 
>> - camel case or underscores within words of names?
>> 
>> - type names begin with capital?
>> 
>> - underscore before or after member names?
>> 
>> - enum values lowercase?
>> 
>> - constant names?
>> 
>> - etc.? :)
>> 
>> Do you have a document that you would like to share?
> 
> There is a "D style guide" in the D spec that briefly mentions naming
> conventions, but I'm not sure how many people use it / are aware of
> its existence.

Here it is: <http://www.digitalmars.com/d/2.0/dstyle.html>.

I've also written a guide on how to name things, but, as far as I know, nobody is following it at the moment. Hopefully it can be improved and serve as the basis for naming things in Phobos (although I'm beginning to be skeptical about that). See <http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines>.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Jarrett Billingsley, el  4 de septiembre a las 22:53 me escribiste:
> On Fri, Sep 4, 2009 at 10:14 PM, bearophile<bearophileHUGS@lycos.com> wrote:
> > Jarrett Billingsley:
> >> I'm consistently confused by D (and Java and C#) code that doesn't indicate member names, especially when they're named really common things that often conflict with local variables, like "len" or "src" or such. Unless the type is small enough to fit on a single screen, it's easy to forget the member names.
> >
> > I usually follow Python usage, and use this.fieldName. Is this bad practice in D?
> 
> It's not bad practice, but it's somewhat unusual for a C-style language, and not enforced by the language, so it's more likely that people won't follow it.

Just as decorating members with '_' or 'm' =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
They love me like I was a brother
They protect me, listen to me
They dug me my very own garden
Gave me sunshine, made me happy

Nice dream, nice dream
Nice dream

bearophile Wrote:

> Jarrett Billingsley:
> > I'm consistently confused by D (and Java and C#) code that doesn't indicate member names, especially when they're named really common things that often conflict with local variables, like "len" or "src" or such. Unless the type is small enough to fit on a single screen, it's easy to forget the member names.
> 
> I usually follow Python usage, and use this.fieldName. Is this bad practice in D?
> 
> Bye,
> bearophile

I haven't coded in python, but in php members are accessed through $this->fieldName, which is just as ugly. I used to name my member variables like any other variable in D (without accessing them with this.) until I confused myself looking back at D code I wrote a year earlier and not being able to tell which variables were function local and which were from the class, which had a nasty superclass stack. I don't like using 'this' to access every member variable since I view it more as a way to access a member shadowed by a local symbol than as a convention, so I declare my member variables with a '_' prefix.