Review of std.net.isemail part 2

[Jacob Carlborg]

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.

> - 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).
>
>
> Thanks,
>
> Andrei


-- 
/Jacob Carlborg