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

From: Bjorn Karlsson (bjorn.karlsson_at_[hidden])
Date: 2001-07-19 05:29:00

> 
> 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.

These are indeed religious statements, and as such, it would be bad if they
were requirements.
However, I fail to see the harm in providing guidelines for those who'd be
interested in using them. The benefits of comformity have been stated
before.
 
> What we do need is better documentation of what the requirements for
> acceptance are.

Agreed, but again - requirements and guidelines are two _very_ different
things. One does not rule out the other.

> 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 ... "
> 
> Mark
> 

I think one of the reasons that coding styles become religion is that
opposing styles often share the same benefits (and therefor the arguments
for or against tend to omit logic reasoning). To put many "best practices"
in a document (instead of one set in a guideline document) just doesn't make
sense if you consider the intent - quality and consistency.

Personally, I am convinced that the guidelines per se isn't the issue (as
long as they are sound), it is the fact that they provide a level of
abstraction by letting you (the reader/writer of code) assume things about
code that follows these guidelines. These assumptions save time, simplify
understanding and help you avoid mistakes.
If we could agree on this, I'm sure we all would appreciate the proposed
guidelines.

As most of the concerns regarding copyright, library acceptance criteria
etceteras have been sorted out, are there more reasons to reject the
document? 

Bjorn