Re: Another ammunition

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Stephen Leake wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
>>The point is, is that a lot of other projects and even team members
>>fail to include the support for this "warning". If it were on by
>>default, there would be uncounted number of hours saved each year
>>by programmers who instead spend the time debugging a problem
>>related to this issue.  I've seen this time and again, even though
>>my team members know about it.
> 
> No tool can substitute for good process, and good education.

I agree with this to some degree, but I would also suggest that
no amount of "good process or education" is a substitute for
bad tools or defaults!

> No tool should be used with only the default command line parameters;

Nobody said that this should be the case. Nobody. So why harp
about this?

What was said was that there are safer defaults.

> the project style guide should say what parameters to specify, and it
> must be enforced.

So do you lock down every developer's PC too, so they can't mess
with their environment?  Programmers are a rebellious lot, and
strict levels of enforcement may work in some environments for
military projects and NASA, but they don't work in many other
environments. Or at least _it isn't done_ ;-)

> The first step in your debug process should be to make sure the proper
> warnings are turned on, and fix all warnings.

No one is doubting this, but there are two problems with this:

   (1) if the developer is working on a large project with
       a ton of warnings already, he's not likely to fix them
       all now. However, if he's smart (and that is not necessarily
       a given ;-), he'd grep for the most important warnings at
       least.

   (2) Some developers (particularly the less experienced ones), do
       not know what to look for, let alone turn on the correct
       compile options.

At least if it was on by default (or with -Wall), then there would
be at least a chance that they'd see it and do something about it.

Note: For a time (if not currently), -Wall did not include _all_
warnings. I believe the return type warning was not included.

>>It is not enough to say "it is not an issue because I do this...".
>>It is an issue, 
> 
> yes, it is. And the proper solution is good process.

I don't buy this. We're going to have to disagree on this point.

>>that could be fixed once and for all. 
> 
> Nope. People who don't like to fix warnings will include the option to
> supress them (that option has to be there, because you do occasionally
> have a legitmate need for it).

Again, nobody (I repeat nobody) said that the option to remove that
warning should be disabled or removed. The statement was, that it
should be on by _default_.

Read my lips ;-) "Nothing more, nothing less."

If you left your house for a vacation, and due to the hustle and
bustle of getting your 3 kids, 2 dogs and your wife all in the
van to go, wouldn't you want to be warned that you forgot to lock
the back door?  Your solution is to strickly depend upon process
and "education". Human nature is such that you cannot _depend_
soley upon this.  This is why Ada does not depend strictly upon
process or education.

>>Even a warning doesn't guarantee that it will be noticed and fixed
>>-- but it greatly increases the odds!
> 
> Not much. As has been pointed out in this thread, many people ignore
> warnings all the time.

Whether its is much or little, I won't argue. You concede that it
is better, and so even that suggests in favour of what I said in the
beginning (change the default).

>>However, the best solution of all is to use Ada instead, and only
>>rely on C like an assembly level layer, when required ;-)
> 
> True. But even for Ada, using the default command line parameters for
> the compiler and linker is bad practice.

Again, nobody is saying that you should use strictly defaults. Nobody!

But having _safer_ defaults is useful and helpful in the general
sense, because _some_ people will use them, irregardless of
your superior education and process. Its like herding cats ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg