[phobos] Initial Phobos style guide proposal

[Jonathan M Davis]

On 2011-03-31 11:39, Andrei Alexandrescu wrote:
> On 3/31/11 12:30 PM, Jonathan M Davis wrote:
> > On 2011-03-31 08:21, Jacob Carlborg wrote:
> >> class Foo
> >> {
> >> 
> >>      int _foo;
> >>      
> >>      int foo () { return _foo; }
> >> 
> >> }
> >> 
> >> But in that case I would still prefer to put the underscore after the
> >> name.
> > 
> > The current style used in Phobos is an underscore before the name.
> 
> This is the perfect example on why such discussions quickly devolve into
> counterproductive exchanges. There's hardly any objective reason for
> placing an underscore before or after a symbol, so we can go with "I
> like it that way" and "Well I like it the other way" forever. Please -
> let's stop.
> 
> I only see two ways out of this:
> 
> - We accept that one person decides;
> - We agree to not decide on it.

I'm all for not deciding then. I'd generally prefer that the style guide not 
be restrictive. And we're talking about a private variable here, so it doesn't 
affect the public API at all.

> Regarding the number of columns, if that's bound to render people
> unhappy and less likely to contribute, absolutely no problem. Make it a
> loose guideline if at all.

I'd definitely prefer no limit, though obviously we should try and be 
reasonable about not making lines overly long. Unfortunately, there's definite 
disagreement on what's "overly long." So, I'm all for not specifying a limit. 
IIRC, the only reason that it came up in the first place was because either 
you or Steve was unhappy about some of my code which didn't stick to an 80 
character limit. There are obviously some of us here who think that an 80 
character limit is good style and others who think that it's horribly 
restrictive and outdated. But if we don't set a limit on it, I don't want to 
have people complaining about line length unless it's obviously way too long 
(and truth be told, some of the unit tests in std.datetime are, since in most 
cases, I specifically avoided having any assert take up more than one line, 
and sometimes what's being tested isn't short).

We need enough of a style guide that it's clear how we're going to be naming 
public (and protected) symbols. We also want to outline any rules or 
restrictions that we all want enforced (like no tabs or indentation levels are 
4 spaces). Some additional suggestions on the preferred way to do things is 
also potentially in order - like unit test as much as is practical. But on the 
whole, I don't see much need to try and nail down much in the way of 
formatting rules. I think that a rule which states that we should try and keep 
modules consistent is reasonable, but beyond that my inclination is to not be 
particularly restrictive.

My main gripe with this sort of thing in the past has been that we haven't 
been restrictive and then there have been complaints about code formatting 
because it didn't fit someone's particular coding style. I want to see this 
situation ironed out so that we can be done with it and not have to worry 
about it again.

- Jonathan M Davis