Tips from the compiler

[Jonathan M Davis]

On Sunday 17 October 2010 22:00:34 Nick Sabalausky wrote:
> > And honestly, I think that things like dangling else, unused variables,
> > and
> > redundant code make a lot more sense it a tool that is looking for
> > potential
> > programming errors rather than the compiler. It's the compiler's job to
> > correctly generate the code that it's given, not worry about all of the
> > possible
> > ways that the programmer could have screwed up when they wrote the code.
> > 
> > - Jonathan M Davis
> 
> The problem I've always seen with lint tools is you have two choices: A.
> Run them occasionally, or B. Set up the build system to run them on every
> compile. So:
> 
> If you do A, you minimize the usefulness because you're not informed of
> potential issues until likely well after they've been introduced into the
> code.
> 
> If you do B, then you may as well just have them built right into the
> compiler. And, in fact, outside of planet Mars, that's what's done: We call
> them "warnings".

The problem is that there are a lot of things that you can warn about which 
aren't necessarily a problem, and it can be really annoying to have to fix a 
bunch of useless warnings. If it really matters, then it should be an error. And 
if it doesn't really matter, then do we need to warn about?

And ultimately, any good programmer is going to fix any warnings, so having much 
in the way of useless warnings is going to either be really annoying or cause 
warnings to be outright ignored.

I'm not entirely against warnings, but I do think that there are a lot of things 
that keep getting proposed as warnings (particularly by Bearophile) which are 
far more likely to be annoying to fix non-problems than to actually be a problem 
and that such warnings would be far better suited to a lint-like tool than the 
compiler.

- Jonathan M Davis