Wish: Variable Not Used Warning

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:g4pplc$gno$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> I don't suppose there's any chance of DMD getting a warning for 
>> variables/arguments that are declared but never accessed? Just today 
>> alone there's been two bugs I spent 10-30 minutes going nuts trying to 
>> track down that turned out to be variables I had intended to use but 
>> forgot to.
>
> The problem with unused variable warnings is they are annoying when you're 
> developing code in an iterative manner. They get in the way when you're 
> commenting out sections of code to try and isolate a problem. They can be 
> a problem when using "version" and "static if" statements.
>
> So, why not just turn off the warnings?
>
> The problem with warnings is that if there are n warnings, there are 
> essentially n factorial different versions of the language.

I really don't see how this is, unless every compiler always has "treat 
warnings as errors" permanently enabled with no way to disable. That's like 
saying that using different lint tools, or different settings within a the 
same lint tool constitutes different versions of the same language, and then 
claiming that means we shouldn't use lint tools.

>  If you're faced with compiling someone else's code (like you downloaded 
> it off the internet and have to compile it because it only is distributed 
> as source) and warnings go off, is that a bug in the code or not? What do 
> you do?
>

By definition, that's not an error. Even if it is a manefestation of a bug, 
that's no reason to deliberately be silent - bugs should be noisy. What do 
you do? Whatever you would normally do when you come across something in a 
program that you're not sure is right or not. It's not an issue that's 
specific (or partucularly relevant, imho) to compiler warnings.

> Some shops have a "thou shall compile with warnings enabled, and there 
> shall be no warning messages."

That's a management problem, not a compiler design problem. (But I'm not 
saying that deliberately minimizing warning conditions is bad. I'm just 
saying that being strict enough that it becomes a problem, ie not balancing 
it with practical common sence, is just begging for trouble, and there's no 
reason we should be bending backwards to help compensate for the bad 
management choices of certain teams.)

> That causes problems when you port the code to a different compiler with a 
> different, even contradictory, notion of what is a warning. So then you 
> wind up putting wacky things in the code just to get the compiler to shut 
> up about the warnings.
>
> Those kind of things tend to interfere with the beauty of the code, and 
> since they are not necessary to the program's logic, they tend to confuse 
> and misdirect the maintenance programmer (why is this variable pointlessly 
> referenced here? Why is this unreachable return statement here? Is this a 
> bug?)
>

Thus comments.

> There is a place for warnings, however. That is in a separate static 
> analysis tool (i.e. lint, coverity, etc.) which can be armed with all 
> kinds of heuristics with which to flag questionable constructs. I don't 
> think they should be part of the compiler, however.

Like I've said, compiler warnings are essentialy a built-in lint tool. I see 
no reason to think of them any other way.