Re: [boost] Review: Boost Coding Guidelines

From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2001-07-16 15:09:17

I feel we should reject this since I don't feel it is appropriate for
Boost to mandate some of the things in these guidelines.  The 
implementation of a Boost library is really up to the discretion of
the submitter; if they happen to prefer foo_ to m_foo, then who are
we to argue?

I realise that this is not the intention of the "guidelines", and 
they are merely supposed to be suggestions, but I don't think they 
will be seen that way.  

What I do think we should do is mandate hard and fast rules about the
things that we do care about, such as

- Use of BOOST_ for macros.

- Namespace usage within boost::.

- Format of names i.e., my_class instead of MyClass.

- Names conformant with the standard, e.g. use empty() rather
  than is_empty(), etc.

But only things that affect the external interface to a class.  
Implementation, including use of spaces, location of change logs,
names of private members, order of class members, etc are really 
none of our concern.

There could also be some suggestions at how to ensure compliance
with the requirements.  For example, I'd ditch 1.5 but say

  Requirement:  Header files must be standalone requiring no other
  headers to be included first.
  Tip: An easy way to verify this is for your source files to 
  include the corresponding header first.

I also don't mind if we have a link to someone's personal site where
more subjective guidelines are proposed, as long as it is clear that
this in no way constitutes a Boost endorsement.

Here is a list of the "guidelines" that I feel may be appropriate to
include in our requirements:

1.4 (also please specify maximum file name length)
1.5 (but turned around as in my comment above)
1.8 (but include more specific advise as to how we want the boost
     directories to be structured)
2.1
2.13 (but with more specific comments about use of BOOST_ in macros)
12.1 (but with more specific comments about how boost:: namespace
     should be structured)
13.1
13.2

Mark