Wish: Variable Not Used Warning

[Bruce Adams]

On Wed, 09 Jul 2008 21:41:35 +0100, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message  
>> news:g530j8$18th$1 at digitalmars.com...
>>> The reason for treating warnings as errors when warnings are enabled  
>>> is so that, for a long build, they don't scroll up and off your screen  
>>> and go unnoticed.
>>  Pardon me for saying so, but that doesn't sound like a very convincing  
>> reason to turn every warning (which, by it's very nature, is something  
>> that might not be a bug) into something that splits the language into  
>> what are effectively different languages.
>
> I'll draw on my 25 years of experience with warnings to answer this.
>
> If you turn warnings on, then you want to see them and presumably deal  
> with them. If you don't deal with them, then they persist every time you  
> compile, and either they get very irritating and you fix them anyway, or  
> you develop a blind spot for them and never see the ones you do want to  
> fix.
>
> Piping the output into a file and then perusing it manually looking for  
> warning statements is never going to happen. Complex builds tend to  
> produce a lot of output, and poking through it looking for warnings  
> every time you build is not practical. Changing your build process to  
> point out warnings is the same thing as the compiler treating them as  
> errors, except it's extra work for the build master.
>
> Trying to educate your programmers into doing extra work to deal with  
> warnings that scroll off the screen is a lost cause.
>
> If you're using a static analysis tool, such as Coverity, which produces  
> lots of spurious warnings, it is not put in the build process. It's run  
> occasionally as a separate evaluation tool.

Focussing mainly on your last point...
Whenever I work with static analysis tools (I'm talking C++ here obviously)
the first thing I do is to put them into the build process right after the  
compiler.
If you run one just occasionally you will get lost in a sea of spurious  
warnings.
Eliminating warnings and hence the slight possibility of error that goes  
with them
takes effort and that effort can be focussed on problem areas.
You can use a different lint configuration for a different set of files  
and gradually
crank up the quality. If necessary enabling one type of warning for only a  
few files
at a time.
A similar approach is to record the warning count and require that it  
never increases
and occasionally work to lower the limit.
Instead of educating programmers to deal with screen fulls of messages the  
focus should be
on educating them that code quality is important and that removing  
warnings is one way of
improving quality. It is not the be all and end all and not nearly as good  
as say automated
testing. Personally I insist on both wherever I can.

Regards,

Bruce.