Re: [boost] Suggested coding guidelines

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-01 09:04:23

----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> In C++, indentation/layout does not prohibit from interfacing a piece of
code
> with another piece of code. Therefore indentation guidelines are
significantly
> less important than identifier decoration rules. The coding conventions
that
> we use at work only specifies the decoration of different type of
identifiers.
> The most important indentation guideline is to avoid using an indentation
that
> is difficult to maintain. An example of a difficult to maintain layout is
the
> endline layout.

Agreed. Would you like to suggest a change based on this?

> The guidelines suggest that include guards should be unique, and then
suggests
> using a date and name. Another alternative is to use a 128-bit GUID per
> project. Using a GUID offers a considerably higher level of protection
against
> collisions. We use a single GUID for all of our libraries, which
internally do
> not have collisions, at work and I don't recall having any collisions with
any
> other library ever.

I think this places too high a burden on the programmer, and that the
proposed method is sufficiently unique. I don't even know how to make a
GUID!

> The guidelines suggest that template parameters should be in mixed case
> without underscores. I have several issues with this:
> - I very much prefer consistent use of underscores regardless of
> capitalization.
> - I also find identifiers with underscores easier to read regardless of
> capitalization.
> - One letter words obscure mixed case identifiers without underscores.
>
>   Example for previous issues:
>
>     ASomewhatDifficultToReadIdentifier
>
>     A_Significantly_More_Readable_Identifier

I agree with you about the readability part, but the guideline is designed
for consistency with the boost:: and std:: legacy.

> - IMO, parameters should be consistently decorated the same as local
> definitions - like in normal function definitions. I have broken this
> principle recently, due to differences in Boost conventions (uses lower
case
> typenames) and the conventions I use at work (mixed case typenames), and
> noticed this only recently. In future, I will consistently decorate
parameters
> the same as local definitions, also in my Boost libraries, regardless of
the
> type of the definition (whether it is a metafunction, function, class or
> whatever).

I need an example to understand this. I think my guidelines are consistent
in this regard (?)

> "8.9. Do not write the `inline' keyword on member function declarations"
> - I recall observing (IIRC, I inspected the disassembly after having link
> errors) that some compilers do not inline such functions. (IIRC, the
compiler
> was some version of MWCW.) So, I would generally advice against this
practice
> if portability is desired.

Older versions of MWCW would only inline functions whose definitions were
visible before the caller's definition, I think. Newer versions have an
option for a kind of lookahead.

Nearly /any/ practice is justifiable at the stage of actually getting a
program to work (or work fast) on a given compiler. These guidelines are
designed to be used up until the time you prove that something else is
neccessary.

-Dave