Wish: Variable Not Used Warning

[Walter Bright]

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.