Notes on the Phobos style guide

[bearophile]

Few comments of mine about this, written by Andrei:
http://lists.puremagic.com/pipermail/phobos/2010-August/001757.html


> * Generally the prevalent Phobos (and I hope D) style is to declare
> local values as late as possible.

Good.
Defining variables at the top of the function/method is positive because it makes the code tidy and it's easy to see in a moment all variables used (Pascal-like languages nearly enforce this). But defining them as close as possible to their usage point has usually bigger advantages that I don't list here. But as usual all rules need to be used in a flexible way.

On the other hand global variables/constants are global both in scope and their definition order doesn't matter, so I think that putting them all at the top of the module is better.


> * In D, use of auto is recommended unless you want to make a
> specific point by mentioning the type.

This is where I don't agree. "auto" is very handy. When you have complex types coming out of lazy map, filter, etc, auto becomes very important, writing code becomes simpler.

On the other hand code needs to be read too, sometimes by people that have not written it. In this case seeing the actual types used is often better. So using "auto" everywhere makes the code reading harder: if you aren't using an IDE that tells you types, you sometimes need to follow the flux of the various calls until you find what is the type, or sometimes you need to add temporary writeln(typeof(x).stringof); inside the code to see what type it is. This problem is common in dynamic languages.

So 'auto' can be abused, online you can find plenty of discussions about disadvantages of 'auto' in C++0x and 'var' in C#. I like the D 'auto' and I use it, but in my opinion it's bad to use it everywhere and to encourage too much its usage. D lacks the flexibility of a dynamic language, so it's not positive to hide too much the types of variables from the person that reads the code.


> * Phobos currently uses full bracing after if, while etc. I've tried to 
> follow that but on occasion I slip. I'm not sure whether we should 
> enforce such rules; this might be a good time to discuss that.

I don't have a definite opinion on this. I am just glad Python has *solved* this class of problems, and it removes some braces-related bugs.


> * Generally I encourage economy of vertical space, e.g.
> auto imp = new File.Impl(fp, 1, host ~ ":" ~ to!string(port));
> f.p = imp;
> =>
> f.p = new File.Impl(fp, 1, host ~ ":" ~ to!string(port));

It's a matter of readability too.
I generally don't like this:

if (...) bar();

I generally prefer (as the Python PEP 8 suggests):

if (...)
    bar();

But in some situations (for example when there are many small short successive ifs), the one-line version is OK:

if (cond1)     bar();
if (condi2)    baz();
if (co3)       spam();
if (condtion4) x++;

Bye,
bearophile