phobos commit, revision 2098


user: dsimcha

msg:
Bug 5035: Schr?\195?\182dinger's Stride

http://www.dsource.org/projects/phobos/changeset/2098

  Bug 5036:  Unicode support on this mailing list really sucks.

On 10/12/2010 8:18 PM, dsource.org wrote:
> phobos commit, revision 2098
>
>
> user: dsimcha
>
> msg:
> Bug 5035: Schr?\195?\182dinger's Stride
>
> http://www.dsource.org/projects/phobos/changeset/2098
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

David, I see some of the code you committed uses a different bracing convention than the existent one. I don't blame you as I myself sometimes forget and use the convention at work when committing into Phobos.

Going forward, do we all agree to go with full bracing and brace on its own line?


Thanks,

Andrei

On 10/12/10 7:18 PM, dsource.org wrote:
> phobos commit, revision 2098
>
>
> user: dsimcha
>
> msg:
> Bug 5035: Schr?\195?\182dinger's Stride
>
> http://www.dsource.org/projects/phobos/changeset/2098
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Monday 03 January 2011 17:05:58 Andrei Alexandrescu wrote:
> David, I see some of the code you committed uses a different bracing convention than the existent one. I don't blame you as I myself sometimes forget and use the convention at work when committing into Phobos.
> 
> Going forward, do we all agree to go with full bracing and brace on its own line?

I cringe to think of how many useless braces I'll have to add to std.datetime to have "full" bracing, but if we want to use that as a convention, then tough luck for me. Personally, I hate full bracing (though I definitely prefer the braces on their own line), but it's not like you're ever going to get everyone to agree on formatting. So, just pick something that you think is reasonable, and hopefully we'll remember to code that way.

- Jonathan M Davis

I think the occasional no full bracing is less of an issue than brace on its own line. And we should observe that stuff for new code - for the time being there's no need to go back and change everything.

Andrei

On 1/3/11 9:32 PM, Jonathan M Davis wrote:
> On Monday 03 January 2011 17:05:58 Andrei Alexandrescu wrote:
>> David, I see some of the code you committed uses a different bracing convention than the existent one. I don't blame you as I myself sometimes forget and use the convention at work when committing into Phobos.
>>
>> Going forward, do we all agree to go with full bracing and brace on its own line?
>
> I cringe to think of how many useless braces I'll have to add to std.datetime to have "full" bracing, but if we want to use that as a convention, then tough luck for me. Personally, I hate full bracing (though I definitely prefer the braces on their own line), but it's not like you're ever going to get everyone to agree on formatting. So, just pick something that you think is reasonable, and hopefully we'll remember to code that way.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Monday 03 January 2011 19:38:25 Andrei Alexandrescu wrote:
> I think the occasional no full bracing is less of an issue than brace on its own line. And we should observe that stuff for new code - for the time being there's no need to go back and change everything.

Well, braces on the same line are a much bigger difference than whether or not full bracing is required. Personally, I skip the braces if both the condition and the body are only one line but use braces otherwise, so that's how std.datetime is. It might get a bit ugly in the lexer code to enforce full braces though, given the sheer number of conditionals and case statements. The C++ version has a number of such where the whole thing is on a single line, which I don't normally ever do, but I think that I may have been leaving them that way when porting them simply because the code gets painfully verbose otherwise. That's not exactly normal code though.

In any case, if we go for full braces and insist on it, then I'll code that way in the future, and if we want to go to the effort of changing old code to match, then I'll make the necessary changes in std.datetime. However, I'd prefer not to if I don't have to.

- Jonathan M Davis

I prefer no full bracing, and braces on their own line.

The only thing I'd say is that bracing is required on nesting.  i.e. this is ok:

if(x)
   blah();
else
   bleh();

but this is not:

if(x)
   if(y)
      blah();
   else
      bleh();

should be:

if(x)
{
   if(y)
     blah();
   else
     bleh();
}


-Steve

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Mon, January 3, 2011 10:38:25 PM
> Subject: Re: [phobos] phobos commit, revision 2098
> 
> I think the occasional no full bracing is less of an issue than brace on its  own line. And we should observe that stuff for new code - for the time being  there's no need to go back and change everything.
> 
> Andrei
> 
> On 1/3/11  9:32 PM, Jonathan M Davis wrote:
> > On Monday 03 January 2011 17:05:58  Andrei Alexandrescu wrote:
> >> David, I see some of the code you  committed uses a different bracing
> >> convention than the existent one.  I don't blame you as I myself
> >> sometimes forget and use the  convention at work when committing into
> >>  Phobos.
> >>
> >> Going forward, do we all agree to go with full  bracing and brace on its own line?
> >
> > I cringe to think  of how many useless braces I'll have to add to
>std.datetime to
> > have  "full" bracing, but if we want to use that as a convention, then tough
>luck
> > for me. Personally, I hate full bracing (though I definitely prefer  the
>braces on
> > their own line), but it's not like you're ever going to  get everyone to
>agree on
> > formatting. So, just pick something that you  think is reasonable, and
>hopefully
> > we'll remember to code that  way.
> >
> > - Jonathan M Davis
> >  _______________________________________________
> > phobos mailing  list
> > phobos at puremagic.com
> >  http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos  mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 

On 1/4/11 9:35 AM, Steve Schveighoffer wrote:
> I prefer no full bracing, and braces on their own line.

I think that's about the dominant style in Phobos now (braces on their own line and quite lax bracing for single statements).

Andrei

On Tue, 4 Jan 2011 07:35:17 -0800 (PST)
Steve Schveighoffer <schveiguy at yahoo.com> wrote:

> I prefer no full bracing, and braces on their own line.
> 
> The only thing I'd say is that bracing is required on nesting.  i.e. this is ok:
> 
> if(x)
>    blah();
> else
>    bleh();
> 
> but this is not:
> 
> if(x)
>    if(y)
>       blah();
>    else
>       bleh();
> 
> should be:
> 
> if(x)
> {
>    if(y)
>      blah();
>    else
>      bleh();
> }

About nested blocks, I think and do the same in practice: omit braces only for a single line, even if the block is a single (compound) statement.
In addition, when no bracing is required because the block is a single-statement, I would still recommend said statement to be systematically on its own line, meaning *not*

	if (foo) bar = 1;

to still visually show the dependance

	if (foo)
	    bar = 1;

But braces on their own line is simply weird and too much a demand for my taste. I cannot guess any rational advantage; do you really find

	if (cond)
	{
	    this();
	    that();
	}
	else
	{
	    this2();
	    that2();
	}

_logically_ more readible than

	if (cond) {
	    this();
	    that();
	} else {
	    this2();
	    that2();
	}

? Or is it just a question of peronal habit?
Instead, I can very well see the drawbacks; especialy uselessly consuming valuable vertical space on screen ;-) I'm not joking, it's a strong nuisance. (*)

Anyway, why not simply use a pretty printer for officially published code (esp Phobos)? It would be run on code just before uploading on the official repository. So that we have a standard style, while developpers can go on using their preferred style one.

I take the opportunity to ask for the rationale of a choice I read on the style guide wiki page: that acronyms should be spelt lowercase (I'm not joking, it's written there http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines#Abbreviations). For instance: toAscii instead of toASCII. I find this an obstacle to readability; even more so because due to "camel case" rule the first letter usually needs to be capitalised, like in the example. Certainly the advantange of toASCII and the disturbance of toAscii are very moderate ;-) But what is the reason for breaking the common rule?

Finally, how can one expect people to follow guidelines the core language itself does not respect? For instance, very few builtin names are conformant, maybe only by accident (single-word func names). And the library unequally follows the style as well.
I would be for having an implicitely imported module of conformant aliases for core builtin names. And have every std module define conformant aliases as well, for every exported symbol.


Denis

(*) I just discovered vertical space is also greatly eaten by the expectation of ddoc for docs to be placed _before_ what the describe instead of _inside_. (So that one cannot even fold a func's doc with the func itself.) Once more feature python had right at once.
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

----- Original Message ----
> From: spir <denis.spir at gmail.com>

> But braces on their own line is simply weird and too much  a demand for my
>taste. I cannot guess any rational advantage; do you really  find
> 
>     if (cond)
>      {
>         this();
>          that();
>     }
>      else
>     {
>          this2();
>         that2();
>      }
> 
> _logically_ more readible than
> 
>     if (cond)  {
>         this();
>          that();
>     } else {
>          this2();
>          that2();
>     }
> 
> ?

Yes.  The inline braces are more difficult to see, they blend in with the if statement.  Plus, it's much easier to match a brace visually with another brace in the same column, instead of matching it with an 'if' or 'while' or whatever statement.

For instance, it's harder to spot a problem in this code:

if(cond1 || cond2)
   blah();
   if(cond3 || cond4) {
      this();
      that();
}

than in this code:

if(cond1 || cond2)
   blah();
   if(cond3 || cond4)
   {
      this();
      that();
}

because the braces obviously don't line up, but in the first, the braces don't line up anyways, you might miss that there is an if statement in the middle and think it's properly braced.

Anyways, this preference is extremely subjective, both ways enjoy huge support in different languages.  There is no "right" answer, but clearly there are functional benefits and drawbacks to both (not just completely one sided as you say).

-Steve