Wed Jan 7 13:38:58 CET 2004
"Robert Virding" <> writes:
> This discussion just goes on :-)
> I still have not seen any good reasons to change my viewpoint, in fact I have got a few to become even more restrictive:
> 1. a+42, 1=2, etc are all legal expressions even if they generate errors when evaluated. As errors have meaning in Erlang then you can't just forbid them.
> 2. Many of the warnings generated by the compiler have been chosen in an extremely ad hoc fashion, they were deemed useful by someone and easy to implement. There is really no clear policy for what is checked and what is not. I mean why check the arguments to io:format and not a host of other common library functions. Especially considering that io:format is easy to guard against. Richard O'Keefe wrote some good stuff about the problems of getting the right level of checking.
The warnings for io:format were implemented because many users often DID
make mistakes. Furthermore, io:formats in error handling might not have been
properly tested, so the first time the error handling code was actually executed
Also, it was not particularily easy to add the io:format code. We have had
quite a bit work keeping the checks correct.
So that is bad example of something we added because it was easy.
> 3. With this in mind then Bjorn's new checks are probably a bad idea, the warnings become even more ad hoc and difficult to understand. I wonder if maybe some of the existing warnings should be removed. I still say that many of the warnings give very little and some are a right pain.***
In old versions of OTP, there were warnings for imports that you didn't use
and for exporting variables out of case statements. We have turned off those
warnings by default.
> 4. You cannot have the option of forbidding legal code, no matter how stupid it may seem. The compiler must handle all legal code. Trying to guess and saying that 90% of the time the user wrote this then they made an error is not good enough. This is similat to the syntax change suggestion concerning =<< made earlier.
I agree. We don't forbid legal code, we just warn about it.
> 5. I wonder if it is good for the compiler to try and use warnings to enforce a certain programming style?
> *** Two warnings that really anoy me are unused vars and unused functions.
> I seldom use '_', the anonymous variable, but prefer to give all variables names so I know what they are, even if I don't use them later. I DON'T LIKE the _Varname convention so why should the compiler try and enforce.
Even if YOU don't like the _Varname convention, other people love it.
Since we started to use the warn_unused_vars option, we have found many
minor bugs in the OTP code. I have also found several bugs in Wings.
That was in WORKING code; in the OTP code we also have extensive test suites.
When I write new code, the warnings immediately inform me about a bug that
otherwise could have taken me some time to find by testing.
> Of course the alternative would be to ALWAYS use it. That would teach the compiler to mind its own business. :-)
You can also use the nowarn_unused_vars option.
> When I define a data structure and its access functions I always define full range of access functions, even those which are not used. I think the structure and how it is intended to be used becomes clearer then. Having the compiler burn me with warnings is irritating to say the least. Yes I can wrap the unused ones in comments but then I don't get any checking.
There should really be a way to turn off the warnings for unused functions.
We might add a mechanism in R10 for doing that.
> This has been done to me in the compiler code.
As we don't want to see the warning in our daily builds, we had to comment
out the functions.
> Anyway what is wrong with defining unused functions? They don't hurt anyone and the compiler removes them from the code anyway.
When maintaining other people's code (I am NOT talking about the compiler
here), you often find stray functions that are left from a previous version
of the module, but is no longer used.
To summarize: IMO, every warning that helps you to find more bugs are
Björn Gustavsson, Erlang/OTP, Ericsson AB
More information about the erlang-questions