Review of std.net.isemail part 2

Jonathan M Davis jmdavisProg at gmx.com
Thu Mar 31 01:27:42 PDT 2011


On 2011-03-31 00:09, Jacob Carlborg wrote:
> On 3/30/11 10:07 PM, Andrei Alexandrescu wrote:
> > On 3/30/11 2:47 PM, Jonathan M Davis wrote:
> >> I've tried to get Andrei to agree to a style guide a few times, but he's
> >> generally pushed back on it. I definitely think that we should have
> >> one if we
> >> want to actually have a consistent style, but thus far, he hasn't
> >> agreed to
> >> have one.
> > 
> > I think that's not representing my viewpoint quite accurately, but
> > getting to the bottom of whatever misunderstanding was there is not
> > important.
> > 
> > It would be helpful to have a broad style guide. The existing one is a
> > good start and is in fact already observed by much of Phobos (and in
> > particular by most of my code). The problem with writing a more
> > elaborate guide is finding the person(s) with the time and inclination
> > to write a draft, get it vetted by the major contributors, and take it
> > to completion.
> 
> Which one is the existing one, it it available on the DigitalMars site?
> 
> > For my money, just take the first that applies:
> > 
> > - Is it a function name? Use thisStyle.
> > 
> > - Is it a value (be it constant or variable)? Use thisStyle.
> > 
> > - Is it a type? Use ThisStyle.
> > 
> > - Is it a module name? Use this_style.
> > 
> > Beyond naming:
> > 
> > - Define variables as late as possible.
> > 
> > - Define constants and other names scoped appropriately.
> > 
> > - Prefer anonymous temporaries to named values within reason.
> > 
> > - Prefer ? : to if/else within reason.
> > 
> > - Prefer compact, effective code to verbose code within reason. Make
> > every line count.
> 
> I don't like this one. I would say prefer readable code to compact code.
> Don't be afraid of having long descriptive names of variables and having
> vertical space in your code. I don't mean you should put three newlines
> between two function declarations but I usually put a newline before and
> after statements:
> 
> int a;
> int b;
> 
> foo();
> bar();
> 
> if (a == b)
>     foo();
> 
> else
>     bar();
> 
> int c = 3;
> 
> > Nitpicks that 9 people have 10 opinions of:
> > 
> > - No 2+ empty lines please. Within a function, an empty line at best
> > should be replaced by a comment describing the meaning of the next block.
> > 
> > - Try to fit functions loosely on one editor page.
> > 
> > - Brace on its own line. (In fact I don't care much either way, but this
> > is the way the majority of the code is.) Note that this does cost more
> > vertical space so it somewhat clashes with the previous point.
> > 
> > - Please avoid > 80 columns unless you feel it induces sterility in the
> > long term.
> 
> Do you know how narrow 80 columns look on a wide screen. I think it
> looks narrow on a regular (non-wide) screen.

I definitely have to agree with you on that one (most everything you said 
actually), but there are obviously differing opinions and it needs to be 
discussed. I've put together an initial proposal for a style guide (based on 
what Phobos has been doing and what's been discussed on the newsgroup) and 
posted it to the Phobos list. So, discuss away on that thread. Hopefully, we 
can come to a reasonable consensus.

- Jonathan M Davis


More information about the Digitalmars-d mailing list