Boost logo

Boost :

From: Ronald Garcia (garcia_at_[hidden])
Date: 2001-07-19 08:44:10

Mark Rodgers writes:
> From: "David Abrahams" <david.abrahams_at_[hidden]>
> >
> In which case why have them? These guidelines contain many religious
> statements and I don't think it is appropriate for Boost to take a stand
> on religious issues.

IMHO, it is appropriate for a boost coding guideline to make some decisions
that are not distinctly "best." While some aspects of coding style
do not appear to show a "best" practice, consistency of style
can contribute immensely to the ability to read and understand code.
Picking SOME solution where several appear equally good provides a
guarantee of consistency.

When first adopting a new style, some aspects may seem awkward to write
and awkward to read simply because old habits take time to change.
But having changed my style countless times, I find that it doesn't
take long before the new format becomes habit and transparent to read.
Being able to carry that transparency into many library reviews,
bug fixes, etc. for boost libraries would be beneficial.

I suspect that in an environment like boost, having to learn a new program
layout style every time one wishes to examine a library detracts from
the benefits that this group offers. If one is reviewing a
proposed library, contributing new features, or fixing bugs, seeing a
consistent style can only help.

At the same time, I think it's important that these guidelines remain
optional. I don't think that boost would reap much benefit from
requiring accepted libraries to be rewritten for style purposes.

Remember that this is an "open source" group. I find it unreasonable
to assume that in the long run only one person will be looking at,
adding to, or modifying any given library. Keeping the barrier of
entry low can improve the quality and quantity of collaboration.
Consistent style can improve accessibility, but it should not lead to
us rejecting quality libraries for style purposes.

Perhaps I change my style so often that my idiosyncrasies haven't
calcified. My concern is where style affects clarity and quality.

> What also might be a appropriate is a "best practices" document
> (completely separate from the requirements) that advises on what you
> should consider putting into your own coding standards. But that would
> avoid religious issues by just highlighting the things you should consider.
> Someone gave a very good example of the sort of thing it should contain
> with regard to naming of member variables - basically "you should probably
> distinguish them and the styles that are popular are ... "

A meta-standard, that specifies the kinds of things one should
consider when crafting a coding standard for c++ is in general,
a good idea for the world of c++ programmers. And I do suspect that
this community could craft such a thing. But I am also of the mind
that a concrete instantiation of such a standard would be
far more beneficial to Boost.


Boost list run by bdawes at, gregod at, cpdaniel at, john at