Re: [Fresco-devel] Coding guidelines again

On Sun, Jun 02, 2002 at 09:56:42PM +0100, [email protected] wrote:
> [snip, and my web-mail-reader lost the attachment anyhow:(]
> 
> A couple of things:
> a) I prefer const's to always be on the RHS, ie. prefer
> int const x;
> to
> const int x;
> since its more consistent with pointer and member-function constness. I 
> also prefer it due to it showing the type first: this is useful when 
> you have a list of function arguments, for example.

Dunno.  Seems like a decent idea to me, but I'm a little bit worried
about getting in the business of legislating finicky things, and this
is perhaps borderline.  Do other people have any
opinions/arguments/aesthetic judgements on this suggestion?

> b) I use const on function parameters even when passing by-value, ie. 
> on pointer and value arguments; even if it makes no efficiency 
> difference, it makes it clear whether you intend to modify it or not. 
> Can use the non-const version in the function declaration, eg:
> void foo(int x);
> void foo(int const x){ /* blah */ }

Personally, I tend to use by-value arguments as scratch variables; it
could be argued that this is a bug in me :-).  I don't quite follow
the argument, though; C++ is very clear about the difference between
passing by value and by reference, so I don't see where the potential
for confusion lies.  (Why should the caller _care_ whether your
implementation uses the argument as a scratch variable, or makes a
copy first?  It's not something that could every possibly effect the
caller...)

> c) when returning by-value, I use const on that parameter too; that 
> avoids problems such as:
> T foo(){/*...*/}
> foo() = 5;
> (unless desired, of course ;)

This signals in error in g++ 2.95 anyway, and probably other
compilers/versions too; I'd be surprised if it didn't.  It says
"Assignment to non-lvalue" or similar.  It's totally non-sensical,
after all...

> d) in initialiser lists, I have the colon or comma starting each line:
> class foo{
> foo()
> : bar(5)
> , baz(6)
> , oomp(7)
> {}
> };
> I find this useful if I'm commenting/changing lines: rather than adding/
> removing comma's to the ends of lines, commenting out a line of the 
> above list requires no extra tidying of the code. The same could be 
> applied to function argument lists too, but I don't currently do that!

Interesting... I agree, trying to comment out initializer lists (with
the standard formatting) definitely sucks.  Maybe you can help us
figure out how to restructure the rules for class declarations to
include this trick?

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein

This email may be read aloud.