Google C++ style guide

Kagamin spam at here.lot
Mon Oct 5 03:34:56 PDT 2009


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.



More information about the Digitalmars-d mailing list