Google C++ style guide

[bearophile]

Jeremie Pelletier:

>I think these are more programming guidelines than language design rules.<

Yes, of course. But programming guidelines can give possible ideas to a language designer, because:
- if everyone is encouraged to follow a certain idiom to avoid bugs, it may be good to let the language itself enforce the idiom (see D that disallows for(...); ).
- if most similar guidelines suggest to not use a certain language feature, such feature may need a redesign, or maybe to be made "less nice" syntax-wise, so the syntax shows its usage is discouraged.
- if in many guidelines suggest to do something in a standard way, to improve uniformity, it may be good to add such thing too to help spreading and transmission of code in the programmer community of that language. One of the causes of Python success is that it forces a very uniform coding style, and this helps people understand and modify each other code, this helps a little the creation of an ecosystem of reusable code. The compile-enforcing of syntax for class attributes in D can be one of such things.


>enforcing parameter order would also break lots of existing code.<

D2 is in flux still, every release breaks existing code.


>I don't recall C having a "ref" keyword :)<

Sorry, I meant C# (CSharp).


>I completely agree here, JavaScript for example has no default parameters and it's annoying as hell. Looking at existing code is really handy to learn about the usage of a function when the documentation is too vague, that documentation is still the best source to learn about the parameters.<

I'm waiting for named arguments too in D :-)


>I barely use alloca at all, since you don't always know if the array is going to be 50 bytes or 20k bytes. If you know the array's size or at least the max size it can get then you can just use a fixed-size array which will get allocated on the stack.<

I was talking about smarter function, that allocates on the heap if the requested size is too much large or if the stack is finishing :-) But of course fixed sized arrays are often enough.


>I don't think this guideline was about the size of integrals but rather their sign bit.<

Right, I meant unsigned integral numbers.


>Yeah I would like overflow tests in D too, although I don't like how you can't control which tests are used and which arent, they're either all enabled or all disabled.<

There are ways to solve this problem/limit. Putting basic tests in is a starting point. I have given LLVM developers some small enhancements requests to implement such tests more efficiently:
http://llvm.org/bugs/show_bug.cgi?id=4916
http://llvm.org/bugs/show_bug.cgi?id=4917
http://llvm.org/bugs/show_bug.cgi?id=4918
I have also discussed this topic with LDC developers, for possible implementations.


>I agree it can get very hard to maintain readability in C++, but D does not have that problem. Templates in D are very elegant and much more powerful than C++'s at the same time.<

D template programming can become very unreadable, trust me :-)


>I think T fits generic template parameters the same way i fits for loops :)<

Sometimes I avoid "i" for loops :-)


>I don't think it should be enforced by the language, it's a great guideline but the programmer should be free to select its flavor (ie m_var, mVar, _var, var_, etc)<

Here I don't agree with you. Uniformity in such thing is important enough.

Bye and thank you for your answers,
bearophile