Naming convention in Phobos

[Don]

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.

All future modules will undergo a review process which will prevent the 
worst naming examples. We will need to initiate a review of existing 
modules at some point. Until that's completed, it would seem to be a bit 
counterproductive to publish a list of rules that 80% of Phobos modules 
break...
But in general, I agree with you.