Re: [boost] Towards a Warning free code policy proposal

Subject: Re: [boost] Towards a Warning free code policy proposal
From: David Abrahams (dave_at_[hidden])
Date: 2010-08-31 10:00:33

First, a clarification:

At Tue, 31 Aug 2010 08:34:31 +0100,
Paul A. Bristow wrote:

This part is Andrey:

> > On Mon, Aug 30, 2010 at 10:55 PM, Andrey Semashev
> > <andrey.semashev_at_[hidden]> wrote:
> > 
> > > My point is that the warning-free requirement (at high levels) seems
> > > quite specific and, to my mind, quite pointless. Additionally,
> > > suppressing all warnings in all Boost headers is (a)
> > > compiler-specific, (b) tedious and (c) may not be what the user
> > > actually wants. Therefore let the users decide what and how to do about
> > warnings.
> 
> I think this is really, really unhelpful.
> 
> And I think there is enough opinions and evidence that getting rid of
> warnings makes the code better.
> 
> So many, perhaps most, people (if not all) believe getting 'warnings free'
> remains a good objective.

And this stuff was posted by me:

> > Here's my suggestion:
> > 
> > * We make no requirement on developers that they address warnings
> 
> We do this now.

Yes.

> > * We choose a warning level we're going to test at for each
> >   compiler
>
> We do this now - but I'd like to see it at W all.

Do we?  Was there any formal decision made, and does anything ensure
that testers aren't overriding that decision in their xxx-config.jam
files?

> > * On our testing pages we publish the number of warnings for each
> > test along with the number of errors
>
> We (someone) could do this, but it might be some work to get a warnings
> count on all systems?

It's well-understood technology.  CTest does it for example.

> (But I note that many warnings arise from libraries when they are used by
> other libraries, for example Boost.Format and Fusion used by Boost.Math.
> This makes warnings count much less useful) .

My point in suggesting the warning count is to provide some incentive
to clear the warnings.  That would happen even for the "transitive
warnings" like the ones you describe.

> > * On our guidelines page we publish a list of safe ways to
> > "avoid".  various warnings (e.g. use implicit conversions) and
> > perhaps less-safe ways to "suppress" them (e.g. use a cast).
> 
> We already have quite a lot on this at
> https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines
> (but more expert input/correction/improvement is very welcome.  You can edit
> it, or I will handle the editorial bit if that is easier).

Wow, I didn't even know about this page.  Nice work, Paul!  OK, then,
IMO the status quo is mostly fine except that we have no metrics to
help developers know how they're doing on warning suppression.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com