Re: [boost] Re: Re: Review: Boost Coding Guidelines

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-07-27 08:38:22

From: "Kevlin Henney" <kevlin_at_[hidden]>

> As the base natural language of C++ and Boost is English, I personally
> prefer to stick to the more easily communicated form, whether written
or
> spoken, where the adjective precedes the noun -- it's a const int not
an
> int const.

This is desirable, but isn't always possible. E.g. if you want a
constant pointer to a non-constant object of type T, you've got no
choice to put the const last: T* const foo;

A tradeoff ensues.  You can optimize for English ordering when possible
or optimize for greatest consistency, i.e. always post-qualified.
Neither choice is inherently right or wrong.  It would be too bad if
this issue was dropped from the guidelines, leaving uninformed people to
make arbitrary decisions, rather than choosing the tradeoff best for
them.

The biggest danger I see with using the prequalified form is that
programmers may get too confortable with that, and end up not marking
pointers as constant because they either don't know that they can or
because it seems unnatural or confusing to do so.

My preference is to always use post-qualified.  It seemed a bit odd at
first when I switched, just as any change to a person's schema would,
but I came to quite like it as it made dealing with more complex
constness situations easier, and I also like the readability of how the
type name ends up being at the very beginning of the expression.

> At best having the qualifier follow the base type name is an
alternative
> to the conventional form, at worst it is rampant political correctness
> without the correctness. Neither of these perspectives suggest that it
> is a best practice ready for inclusion in coding guidelines. I would
> suggest that rather than spark a slow-burning flame the recommendation
> of qualifier placement should be dropped entirely from the
guidelines --
> as you say, it is doubtful that this point will ever be agreed upon.

I believe this understates the issue.  While both options are valid, the
ramifications are significant enough that a concensus on a better choice
is possible.  I don't the guidelines as sparking the flame; the language
did that.  The best way to control it is to have the tradeoffs and
rationalles documented in a logical place; otherwise, the issue
continuously resurfaces for rehashing.