[phobos] Initial Phobos style guide proposal

[Jonathan M Davis]

On 2011-03-31 11:39, Jacob Carlborg wrote:
> On 31 mar 2011, at 19:30, Jonathan M Davis wrote:
> > The current style used in Phobos is an underscore before the name. It's
> > also likely to be frequent that a member variable has a property which
> > goes with it, meaning that it _has_ to be named slightly differently.
> > How much the exact naming scheme matters though depends on how much
> > consistency we want within Phobos. It's _not_ part of the public API, so
> > it's purely a matter of consistency in coding style. If we don't care
> > all that much in keeping all of Phobos' internal stuff consistent in
> > style, then this sort of rule isn't necessary. If we want obe consistent
> > though, a choice needs to be made, and the underscore before is
> > currently what's being used (it's also what I, personally, prefer - as
> > does Andrei, I believ). But really, the main question is whether we
> > _want_ to be this exacting about private names.
> 
> What about public members? Wouldn't it be a little inconsistent to have
> public members named with camel case and private members with a leading
> underscore or is that the whole point?

If a member variable is public, then it's effectively a property. It's just a 
variable instead of a function. And it could be replaced by a property 
function later - generally with the idea that client code would not have to be 
changed. Private member variables are different beasts altogether. It is 
common to give private member variables a naming convention which differs from 
local variables in order to distinguish them. When you have properties with 
the same names, then it becomes a necessity.

Now, it's fine with me if we don't dictate how member variables are named - as 
long as it's understood that they will not always match the normal naming 
scheme. Personally, I use a leading underscore. I also don't like it when 
there's mixture of styles between private member variables (e.g. some with an 
underscore nad some without), but that's my personal preference. The only 
reason I see to select a style is if we want Phobos to be consistent. But 
while some people think that Phobos should be highly consistent in its styling 
throughout, I don't think that it necessarily matters. What matters is the 
public API. _That_ should strive for consistency, because that affects the 
users of the library. The style of the implementation details does not.

- Jonathan M Davis