Naming convention in Phobos

[Jim]

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.