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.
