Naming convention in Phobos

[Jonas Drewsen]

On 06/03/11 18.50, Jim wrote:
> Jonathan M Davis Wrote:
>
>> On Sunday 06 March 2011 02:59:25 Jim wrote:
>>> Okay, so there's a discussion about identifier names in the proposed
>>> std.path replacement -- should they be abbreviated or not? Should we
>>> perhaps seek to have a consistent naming convention for all identifier
>>> names in Phobos?
>>>
>>>
>>> Some of the potential benefits:
>>>
>>> • Legibility, understandability and clarity (reduce ambiguity).
>>> • Ease in finding a suitable function/class by name.
>>> • Knowing if it's a cheap or costly function call.
>>> • Aesthetics and professional appearance.
>>>
>>>
>>> Some properties that I can think of for discussion:
>>>
>>> • Abbreviation (and if so, what to abbreviate and how much)?
>>> • Preference of commonly used terms in other languages, contexts?
>>> • Use of get and set prefixes or not (getName() or simply name())?
>>> • Explicit use of a prefix (example: calc or calculate) for costly
>>> operations? • Naming of function and template arguments?
>>> • Uppercase, lowercase, camelcase, underscore in multi-word names? All caps
>>> for constants, or different appearance for different types (types,
>>> functions, arguments, constants...). What about acronyms: TCP, Tcp?
>>>
>>> Are there other concerns?
>>
>> The general naming convention as far as variable names go is camelcased with the
>> name starting with a lower case letter - this includes constants. Most of Phobos
>> follows this, and the parts that haven't been have been moving towards it. There
>> are likely to be a few exceptions, but on the whole, that's how it's supposed to
>> be. Type names are the same, except they start with an upper case letter (this
>> includes enum names - the enum values are capitalized the same as any other
>> variables however). That's the way it has been, and that's the way that it's
>> pretty much guaranteed to stay.
>>
>> Generally speaking, we want descriptive names, and I think that it's safe to say
>> that we don't want overly long names, so if we can have descriptive but short
>> names, that's generally best. get and set prefixes are likely to be rare, because
>> most of such functions will be properties, and properties will normally have
>> nouns for names and won't use get or set, but I don't think that we want to say
>> that we'll _never_ have function names prefixed with get or set. Normally, we
>> won't, but it's going to be very situation-dependent.
>>
>> Now, as for the rest of it, I don't really want to get into a big discussion of
>> the best way to name everything. It's far too context-dependent and very quickly
>> turns towards bike shedding. I think that it's appropriate for anyone who's
>> developing a module for Phobos to come up with names that they think are
>> reasonable and which follow the very basic naming conventions that we follow,
>> and then have names adjusted as needed during the review process. I really don't
>> think that we're going to get much of value by having a big discussion over
>> general naming conventions. It seems to me like it's just going to be a classic
>> situation for bike shedding and generally useless discussion. What we've been
>> doing generally works just fine.
>>
>> - Jonathan M Davis
>
> All right, thanks for the courteous reply. Considering the other comments in this thread I think there isn't much interest in working out or agreeing on a few good principles or guidelines for naming identifiers in Phobos. Otherwise, even if we could only agree on a few of them, they could be written down somewhere, should anyone someday be inclined to join the development.

Funny you mention it. I was actually looking for such guidelines a 
couple of days ago on both digitalmars.com and d-programming-language. I 
ended up having to look at the phobos source code to get an idea of the 
style. So thumbs up from here on having such guidelines.

/Jonas