www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D naming style?

reply Ali Cehreli <acehreli yahoo.com> writes:
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
Sep 04 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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.
Sep 04 2009
next sibling parent reply Ali Cehreli <acehreli yahoo.com> writes:
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
Sep 04 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 04 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
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
Sep 05 2009
prev sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
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.
Sep 05 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
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

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.
Sep 04 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Sep 05 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Michel Fortin Wrote:

 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/

I just read your guide, it follows a lot of the logic I already use myself. But I think you need more explanations to justify your rules; I believe it is way easier for someone to remember something if they know and understand why they should remember it. Also, about your bit on wchar vs wchar_t. wchar in D is fixed to 16bit while wchar_t is 16bit on Windows but 32bit on linux, some people care about differences like that, or learn them the hard way like I did: from segmentation faults!
Sep 05 2009
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Michel Fortin wrote:
<snip>
 Here it is: <http://www.digitalmars.com/d/2.0/dstyle.html>.

My style more or less resembles this, except: - Each indentation level is a tab character (by far the most sensible way to do things) - Usually one blank line between class methods, and two between module-level declarations - I nearly always use /+ ... +/ or // to comment out code - I've variously used UpperCamelCase or ALL_CAPS for enum names, though for enum value names it's always ALL_CAPS. (Phobos breaks both these rules in places, e.g. FileMode.Out.)
 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>.

1. That page contradicts itself - first `Accessor functions can be nouns, adjectives, or third-person verbs with an object.` then `Boolean properties should start with "is", "has", or a modal verb such as "can" and "should".` even giving "enabled" as an example in each case. 2. `[should we allow some exceptions here? sin(x) comes to mind] ` What is this supposed to mean? 3. One-letter parameter names are, IMO, OK for property setters and maybe other cases where the nature of the parameter is obvious from the function name. And when they're the likes of 'x' and 'y' for Cartesian coordinates and what they're the coordinates of is obvious. But otherwise, I agree that they ought to be avoided. 4. Maybe you could add something on the question of what to name the internal variable that keeps track of a property's value, in order to distinguish it from the property itself. I personally tend to use the property name prefixed by an underscore. Stewart.
Sep 06 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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.
Sep 04 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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.
Sep 04 2009