Wish: Variable Not Used Warning

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:g537q0$1vi0$1 at digitalmars.com...
> 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.
>

First of all, if you don't want to deal with warnings, then along with what 
you said, you presumably wouldn't have turned them on in the first place. So 
I'm not sure you'd be developing a blind spot (unless you're being required 
to use them, which goes back to the management discussion).

Aside from that, I'll fully agree that cerain warnings can get annoying and 
eventually overlooked, *if* you're using a language like C/C++ that has 
accumulated decades of warnings that resulted from design issues that could 
have been fixed by a design change but never were simply because maintaining 
full backwards compatibility (across all those years) was considered more 
important than never fixing a problem properly. D's not really in that boat. 
But even if it did end up in that boat someday, I'd much rather have the 
*chance* of not noticing a particular warning, than be guaranteed never to 
notice it simply because it was decided not to even offer the warning out of 
fear that it might get ignored.

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

I think you misunderstood me. What I was talking about would only involve 
the makers of things like rebuild or make. All we need is a cumulative "x 
errors, x warnings" at the end of the build process. That's enough to let 
people know that there were warnings they should scroll up and look at (if 
they care about warnings in the first place). That would elininate the need 
to always force warnings as errors out of the mere worry that someone might 
not see it because it scrolled away.

And if a so-called "programmer" has a problem looking at the "x errors, x 
warnings" display, then they themselves are already a lost cause, period. I 
don't to have to put up with gimped tools just because some incompetent 
morons are masquerading as real programmers.

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

I can agree with that, but with the caveat that I, for one, would at the 
very least choose the most useful subset of those warnings to run during 
each compile.

As an example, the last time I was using ActionScript 1 (ECMAScript without 
any of the improvements from v3 or beyond), I was constantly running into 
problems that a compiler like DMD would have caught (and considered errors) 
but ended up spending half an hour, a full hour, etc, trying to debug. I 
incorporated a JavaScript lint tool into my workflow (ran it every time I 
saved and was about to test something), and it helped immensely. Never gave 
me any problem.

My point is, I *do* want certain warnings to be checked for on every 
compile. Now yes, there can be extra ones that are really anal and only 
occasionally useful. But in a normal setup where warnings are only 
*optionally* treated as errors *and* I can select which warnings I want, 
then those really anal annoying warnings can just be run on occasion, and I 
can still have my more common and highly-useful ones caught right away - 
which is what I want. And I seriously doubt I'm any sort exceptional case by 
feeling that way about it.