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.

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.


Andrei

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?

> I would love that and think that it would be a _big_ improvement, but there are some folks (Andrei in particular) who seem to really not like code going beyond 80 characters. I do know that there are other Phobos devs who _do_ want longer line lengths though, so maybe we can change this. Where this really gets to be a problem is with lines with several levels of indentation, and trying to restrict the line length (particularly to something short like 80 characters) tends to encourage overly short and non-descriptive variable and function names, which is _not_ good.

Can't everyone that likes to keep the horizontal length to 80 characters use word wrapping?

-- 
/Jacob Carlborg

On 3/31/11 1:39 PM, Jacob Carlborg wrote:
>> I would love that and think that it would be a _big_ improvement, but there are some folks (Andrei in particular) who seem to really not like code going beyond 80 characters. I do know that there are other Phobos devs who _do_ want longer line lengths though, so maybe we can change this. Where this really gets to be a problem is with lines with several levels of indentation, and trying to restrict the line length (particularly to something short like 80 characters) tends to encourage overly short and non-descriptive variable and function names, which is _not_ good.
>
> Can't everyone that likes to keep the horizontal length to 80 characters use word wrapping?

No, and please let's not take this one bit further.

Regarding this:

> I absolutely think that I function should fit within a page of code but the way to do that is NOT to write more compact code vertically. It's to split the function in several smaller ones, split the classes in smaller ones and split the modules smaller ones. That is clearly something that Andrei and Walter doesn't seem to understand.

I'd opine that it's a bit assuming. Essentially it says that people who don't code the way you like it are incapable of understanding elementary modularity.


Thanks,

Andrei

On 31 mar 2011, at 20: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.
> 
> 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 don't care if it's a leading or trailing underscore but I don't want to add an underscore when there's no reason, ie. no matching getter/setter.

> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

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

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

On 31 mar 2011, at 20:58, Andrei Alexandrescu wrote:

> On 3/31/11 1:39 PM, Jacob Carlborg wrote:
>>> I would love that and think that it would be a _big_ improvement, but there are some folks (Andrei in particular) who seem to really not like code going beyond 80 characters. I do know that there are other Phobos devs who _do_ want longer line lengths though, so maybe we can change this. Where this really gets to be a problem is with lines with several levels of indentation, and trying to restrict the line length (particularly to something short like 80 characters) tends to encourage overly short and non-descriptive variable and function names, which is _not_ good.
>> 
>> Can't everyone that likes to keep the horizontal length to 80 characters use word wrapping?
> 
> No, and please let's not take this one bit further.

So you just want to end the discussion when someone disagrees with you?

> Regarding this:
> 
>> I absolutely think that I function should fit within a page of code but the way to do that is NOT to write more compact code vertically. It's to split the function in several smaller ones, split the classes in smaller ones and split the modules smaller ones. That is clearly something that Andrei and Walter doesn't seem to understand.
> 
> I'd opine that it's a bit assuming. Essentially it says that people who don't code the way you like it are incapable of understanding elementary modularity.

I can not understand how anyone can call a module containing 25k+ lines of code modular.

> Thanks,
> 
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

On 3/31/11 3:20 PM, Jacob Carlborg wrote:
>
> On 31 mar 2011, at 20:58, Andrei Alexandrescu wrote:
>
>> On 3/31/11 1:39 PM, Jacob Carlborg wrote:
>>>> I would love that and think that it would be a _big_ improvement, but there are some folks (Andrei in particular) who seem to really not like code going beyond 80 characters. I do know that there are other Phobos devs who _do_ want longer line lengths though, so maybe we can change this. Where this really gets to be a problem is with lines with several levels of indentation, and trying to restrict the line length (particularly to something short like 80 characters) tends to encourage overly short and non-descriptive variable and function names, which is _not_ good.
>>>
>>> Can't everyone that likes to keep the horizontal length to 80 characters use word wrapping?
>>
>> No, and please let's not take this one bit further.
>
> So you just want to end the discussion when someone disagrees with you?

This is a misunderstanding. I just wanted to preempt a discussion along the lines "but why?" to which some arguments would be made followed by "but you could try X, would that work?" etc. People have tried, and for the time being there is no satisfactory solution for auto wrapping.


Andrei

Non-bikeshed issue!

> - Type names are camelcased and begin with an uppercase letter.
>
> - Function and variable names and named values (including enum values) are ?camelcased and begin with a lowercase letter.

This is good for aggregate types and named enums,  but applying the
same rule for manifest constants is too strict.
(Please note that manifest constants are not the same as members of
named enums).
It's a particular problem for mathematical constants and values derived from C.

Generally speaking, camelCase works very poorly for global values
which are single words, because they are indistinguishable from
lowercase.
This isn't really a problem for functions, since you still have the
parentheses (All functions use camelCase, so if it is a function call,
it must be camelCase!)
Furthermore, I don't think there should be any global variables which
are single words, so it's really only an issue for manifest constants.
It is also potentially an issue for static functions defined at global
scope, which are callable using property syntax, but this is easier to
fix: such beasts, if ever truly necessary, should not be single words.
You need a very good reason for defining a value in global scope. And
an even better reason to have one which is only one word long. But
some do exist.
The classic examples are E and PI.

Java's style guide (the one from Sun) states:
The names of variables declared class constants and of ANSI constants
should be all uppercase with words separated by underscores ("_").
(ANSI constants should be avoided, for ease of debugging.)
To the best of my knowledge Python, Perl, Ruby, C, C++ all do the same.

IMHO we need a very, very good reason to do something different. And I don't think any other option can realistically be consistent. As well as the math constants, consider the Windows headers (and pretty much anything else derived from C).

Please note that I think we should strongly discourage naked constants
defined at global scope. So I would hope that the issue doesn't arise
very often.
Thus, I propose:

- global variables, and static functions defined in global scope which
are callable using property syntax, must have names which are more
than word long.
- public manifest constants defined in global scope should generally
be avoided. When they do need to exist, they should have names which
are all uppercase.

On 3/30/2011 8:00 PM, Jonathan M Davis wrote:
> These are intended to be general guidelines which are followed most of the time but can be broken within reason (though hopefully that's relatively rare).
>

I'd like to see this as changes (as necessary) to the D style guide http://www.digitalmars.com/d/2.0/dstyle.html, not as something distinct and possibly in contradiction with it.