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!

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.