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
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
parent reply 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. :)



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
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:


 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 reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Sep 4, 2009 at 10:14 PM, bearophile<bearophileHUGS lycos.com> wrote:

 Jarrett Billingsley:


 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
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:


 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:


 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


 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. :)


 

 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