bearophile Wrote:

> >Function Parameter Ordering: When defining a function, parameter order is: 
> >inputs, then outputs.<
> 
> D may even enforce this, allowing "out" only after "in" arguments.

I'm trying to do the reverse. Maybe I used fprintf and sprintf too much.

> >Static and Global Variables: Static or global variables of class type are 
> >forbidden: they cause hard-to-find bugs due to indeterminate order of 
> >construction and destruction. [...] The order in which class constructors, 
> >destructors, and initializers for static variables are called is only 
> >partially specified in C++ and can even change from build to build, which 
> >can cause bugs that are difficult to find. [...] As a result we only allow 
> >static variables to contain POD data.<
> 
> I think D avoids such problem.

No. D has static constructors which do the same.

> >Doing Work in Constructors: Do only trivial initialization in a constructor. 
> >If at all possible, use an Init() method for non-trivial initialization. 
> >[...] If the work calls virtual functions, these calls will not get 
> >dispatched to the subclass implementations. Future modification to your 
> >class can quietly introduce this problem even if your class is not currently 
> >subclassed, causing much confusion.<
>

Never understood this advice to split the construction of object? What is it 
trying to solve? And how they plan to not dispatch calls to subclasses? Do they 
overwrite vtbl at the end of constructor? In fact DMD has bug here: spec says, 
this pointer must not be taken implicitly or explicitly, yet dmd allows calling 
virtual methods on the object being constructed.

> >Declaration Order: Use the specified order of declarations within a class: 
> >public: before private:, methods before data members (variables), etc.<
> 
> D may even enforce such order (Pascal does something similar).

Methods before data seems unnatural for me.

> >Decision: If you want to overload a function, consider qualifying the name 
> >with some information about the arguments, e.g., AppendString(), AppendInt() 
> >rather than just Append().<
> 
> 
> This is a strong limitation. One of the things that makes C++ more handy than 
> C. I accept it for normal code, but I refuse it for "library code". Library 
> code is designed to be more flexible and reusable, making syntax simpler, etc.
> So I want D to keep overloaded functions.

A good example is BinaryWriter. It's unusable when implemented with overloaded 
methods.

> >Default Arguments: We do not allow default function parameters.<
> 
> >Decision: We require all arguments to be explicitly specified, to force 
> >programmers to consider the API and the values they are passing for each 
> >argument rather than silently accepting defaults they may not be aware of.<
> 

Is it a solution? Default parameters can be emulated by overloads with 
different number of parameters, which call actual method with defaults for the 
rest of the parameters. They just propose to always use the full api? How about 
going back to asm to consider your code rather than accepting compiler magic?

> Integer Types:
> 
> >You should not use the unsigned integer types such as uint32_t, unless the 
> >quantity you are representing is really a bit pattern rather than a number, 
> >or unless you need defined twos-complement overflow. In particular, do not 
> >use unsigned types to say a number will never be negative. Instead, use 
> >assertions for this.<
> 
> I'm for the removal of size_t from everywhere it's not stricly necessary (so 
> for example from array lenghts) to avoid bugs.

Yess, unsigneds are evil. They must go to the camp of gotos and unsafe pointers.

> Type Names: often I don't like the C++ practice of using a single uppercase 
> letter for a template type, like T. Better to give a meaningful name to 
> types, when possible.
> 

I thought it's a common practice that the length (meaningfulness) of the name 
of a variable is determined more by the size of its scope rather than its 
purpose.

> >Spaces vs. Tabs: Use only spaces, and indent 2 spaces at a time.<
> 
> 4 spaces are more readable :-)
> 

I prefer 3. 4 is too much. Almost every editor has the option to specify the 
tab width and people have different tastes.

Reply via email to