Google C++ style guide

[Justin Johansson]

Jérôme M. Berger Wrote:

> bearophile wrote:
> > I have found this page linked from Reddit (click "Toggle all summaries" at the top to read the full page):
> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
> > 
> > At Google C++ isn't the most used language, so it may be better to use a C++ style guide from a firm that uses C++ more than Google. On the other hand Google has hired many good programmers, and probably some of them have strong C++ experience, so if you are interested in C++/D this style guide deserves to be read.
> > 
> > This guide is mostly (as it often happens with C++) a list of features that are forbidden, I think usually to reduce the total bug count of the programs. Some of such imposed limits make me a little nervous, so I'd like to remove/relax some of those limits, but I am ignorant regarding C++, while the people that have written this document are expert, so their judgement has weight.
> > 
> > They forbid several features that are present in D too. Does it means D has to drop such features (or make them less "natural", so the syntax discourages their use)?
> > 
> > Here are few things from that document that I think are somehow interesting. Some of those things may be added to D style guide, or they may even suggest changes in the language itself.
> > 
> > -------------------
> > 
> >> 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 actually use the inverse convention: "out" arguments come first. 
> This way, it is easy to see that "a = b" and "assign (a, b)" modify 
> "a" and not "b".
> 
> 		Jerome

Ditto.  A special use case to consider is when you have a function template that returns a type
that is a template parameter and the types of the function arguments are also template parameters.

Often type inference can be used to determine the type of the function arguments without explicit
qualification of the argument types in the instantiation.  The return type must be specified however,
since inference cannot be made from missing information.

This suggests a natural order that results (and out arguments) should be on the LHS and (in) arguments
on the RHS.

So if one writes this:

R Foo(R, A1, A2)( A1 arg1, A2 arg2) {
  R r;
  return r;
}

auto r = Foo!(double)( 3, 4);

Isn't it more natural or consistent to write this also:

void Bar(R, A1, A2)( out R r, A1 arg1, A2 arg2) {
}

double r;
Bar!(double)( 3, 4);

I haven't tried it so not sure if this works but you get the idea.

Another reason why outs/inouts should be before in arguments is in the case of functions
taking variable length argument lists or variadic arguments.  Normally there is only one
output argument but there is an arbitrary number of input arguments that the function
can take.

Yet another reason why so is by analogy with output stream functions; an output stream
argument is analogous to an output value or reference.

Nearly all I/O libraries that I've seen have usage like this:

fprintf( stdout, /+args...+/);

write( os, value);

Rarely the other way around, namely, input arguments before output stream/file channel argument.

-- Justin Johansson