Date: 2001-07-17 07:45:31
I'm going to add my voice to Paul and Mark for rejection here. When the idea of
coding guidelines was originally raised I thought it would be a good idea.
However, the content of the current guidelines isn't at all what I believe would
be consistent with boost. I was interested in rules of thumb that improve the
quality of written code. Each guideline item conveying a clear rational and
I believe sections 3-5, 7 and 10 should be removed because all the elements
discuss code formatting and commenting. By definition, these are targeted at
human readers and at some level will become "religious issues". At the very
least, these are going to get in the way of accepting the useful stuff.
And there are problems in other places. Just to pick one guideline out of the
group as an example:
11.16. Step through each line of code you write or change in a debugger. This
includes error-handling code. It is OK to artificially stimulate error
conditions for debugging purposes. See ``Writing Solid Code.''
This is silly. No one has time to bother making sure that something like
int i = 10;
will work. And besides, there are plenty of ways to validate program functions
that have nothing to do with using a debugger. This is really a project/testing
guideline not a coding guideline.
So, while I haven't had time to read the detail of every last guideline (let
alone follow the entire thread) I don't think the current guidelines can get the
high standards of boost without major rework.
And finally, with the All Rights Reserved copyright, anyone that wants to modify
the guidelines for their own purposes, will have to ask David and Nathan for
permission. This would be the only item in boost with this standard. I have
absolutely no problem with David and Nathan wanting to maintain rights to
publication etc, but then they shouldn't be part of boost. In my opinion they
should have the same rules as code to be accepted into boost:
-->Must grant permission to copy, use and modify the software for any use
(commercial and non-commercial) for no fee.
> -----Original Message-----
> From: Moore, Paul [mailto:paul.moore_at_[hidden]]
> Sent: Tuesday, July 17, 2001 6:01 AM
> To: 'boost_at_[hidden]'
> Subject: [boost] Re: Review: Boost Coding Guidelines
> From: Peter Dimov
> > From: "Beman Dawes" <bdawes_at_[hidden]>
> > [...]
> >> If all those safeguards are in place, do you still think there is too
> >> danger the guidelines will be seen as requirements?
> > It all comes down to:
> > If I submit a library to boost, and this library hasn't even heard of the
> > boost guidelines,
> > 1. Will this be a reason for rejection?
> > 2. Will this generate several hundred of review comments along the lines
> > "Why don't you follow guideline x.y?"
> And a comment from someone who already has an accepted library:
> 1. Will rationa be expected to change to conform?
> 2. Will I be expected to do the work?
> 3. Which bits of the document are mandatory vs optional? (Yes, I did read
> the document - admittedly only quickly - and no, it isn't clear).
> I vote for rejection - not because of any particular failings, but because I
> don't see the point. (As someone else pointed out, things would be different
> if library maintenance was done by the group, rather than by individuals).
> Info: http://www.boost.org Unsubscribe:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk