Re: [Fresco-devel] Coding guidelines again

njs wrote: (?)
> On Sun, Jun 02, 2002 at 09:56:42PM +0100, [email protected] 
wrote:

> > 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?

Well the rule could maybe have a similar motivation to that for having 
return types on their own line; is it better to have:
some_type const & 
some_function();
or
const some_type &
some_function();
?

> > 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...)

The 'potential for confusion' is not between passing by value and 
reference, and is not about the function as seen by the caller. Rightly,
in the function declaration *doesn't care* whether the argument itself 
is const; but in the implementation it is valid to insert a const, for 
the benefit of readers. Personally I find it better not to reuse an 
input argument for another different purpose, where the variable name 
then becomes inappropriate; if I want a variable for a different 
purpose, I make a specific one. IMO this is clearer. This also makes it 
clear that wherever you refer to the function argument within the 
function, it will have the same value; in a 'long' function it is 
useful to know that you don't have to track any changes to the variable 
through the function duration. Basically the same reason that you might 
have a const here:

void some_function()
{
int const a = some_complicated_expression();
// ...
// some code
// ...
// a is still the same value here
}

then why not have a const here:

void some_function(int const a)
{
// ...
// a is still the same value here
}

Perhaps this is not significant, but perhaps just being a 'prefer' rule.
Good idea, or not?

> > 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...

I missed the more-useful case; what about:
if(foo()=5){
If foo() returns by const value, then this will flag an error, which is 
definitely helpful IMO :)

> > 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?

What more do you need to know?

-----
If you have an initializer list, put the colon on the line after the 
closing ')' of the parameter section, indented an additional level. The 
first initialiser is separated by a space from the colon, and 
subsequent initialisers are placed on their own lines, with commas 
aligned beneath the colon. For example:
--
Constructor(some argument)
: first_thing(value)
, second_thing(2,3)
, third_thing('c')
{
--
Justification: makes it easier to comment-out individual initialisers, 
line-by-line. At most you must overwrite characters to replace a colon 
by a comma or vice versa.
----------------
That OK?

function arguments don't work quite as well: you'd need something like:


void some_function
(argument1
,argument2
,argument3
)
{

This is slightly more messy, IMO!

-- 
Neil hopes this message goes through properly, unlike the last.