Review of std.net.isemail part 2

[Jonathan M Davis]

On 2011-03-30 13:07, 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.

I'll throw something together within the next day or two. It shouldn't take 
long. What'll be harder is getting people to actually read it and agree on it. 
Most discussions on this sort of thing in the past haven't generated much 
discussion even when people seem to definitely care (of course, the Phobos 
list seems pretty quiet of late, and the general activity for commits to 
Phobos from the Phobos dev team as a whole seems pretty low ever since we 
switched to git - whether that's the switch is related or not, I don't know). 
Still, we should get something going. The more that people are looking to 
contribute to Phobos, the clearer that we need to be on style requirements and 
guidelines.

> 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.

This would be a good example of something that's never been agreed on AFAIK. 
Does any module in Phobos use this_style? I'm not necessarily opposed, but I 
don't think that it's been used yet.

> 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.
> 
> 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.
> 
> - No tabs please.
> 
> - Comments should be high level (describing 3-10 lines) instead of
> low-level (describing the mechanics of the next line, which are already
> obvious in code).

Some of these are certainly debatable, but are overall good. We can discuss it 
as part of reviewing an actual style document though.

- Jonathan M Davis