Re: D naming style?
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.
Re: D naming style?
On 2009-09-04 21:07:01 -0400, Jarrett Billingsley jarrett.billings...@gmail.com said: On Fri, Sep 4, 2009 at 8:42 PM, Ali Cehreliacehr...@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.for...@michelf.com http://michelf.com/
Re: D naming style?
Jarrett Billingsley, el 4 de septiembre a las 22:53 me escribiste: On Fri, Sep 4, 2009 at 10:14 PM, bearophilebearophileh...@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
Re: D naming style?
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.
Re: D naming style?
Michel Fortin Wrote: On 2009-09-04 21:07:01 -0400, Jarrett Billingsley jarrett.billings...@gmail.com said: On Fri, Sep 4, 2009 at 8:42 PM, Ali Cehreliacehr...@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.for...@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!
D naming style?
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
Re: D naming style?
On Fri, Sep 4, 2009 at 8:42 PM, Ali Cehreliacehr...@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.
Re: D naming style?
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
Re: D naming style?
On Fri, Sep 4, 2009 at 9:18 PM, Ali Cehreliacehr...@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.
Re: D naming style?
On Fri, Sep 4, 2009 at 10:14 PM, bearophilebearophileh...@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.
Re: D naming style?
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
Re: D naming style?
Jarrett Billingsley wrote: On Fri, Sep 4, 2009 at 9:18 PM, Ali Cehreliacehr...@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.
