Safety features
Safety features
Posted Sep 18, 2014 14:09 UTC (Thu) by man_ls (guest, #15091)In reply to: The road to Rust 1.0 by Wol
Parent article: The road to Rust 1.0
I agree with most of your message except for this point:
All these safety features should be *easy to disable* but *turned on by default!!!*.If I understood correctly you turn all warnings to errors by default. That is not as useful as it looks.
Take Go for instance. It complains loudly about, and will not run a program with, one unused variable. The first part is admissible; the second is a huge pain in the neck. Just try to comment a section of code, and then your code will not compile; you have to also comment some random import at the top because suddenly it is no longer required (because of the code you commented).
I like warnings, but being able to ignore them in a pinch (or for rapid prototyping) is important also. At the same time I don't want to disable them altogether because that would open the door to unpleasant bugs (or worse, ugly code) in production. So I may live with a few warnings during development, but check thoroughly all code before deploying it, to get the best of both worlds.
Posted Sep 19, 2014 1:11 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
When I maintained an MS C v5 program, I took it over, and did exactly that, switching on max level warnings (level 3, it was then). Oh my God, the piles of warnings it produced! Which I steadily eliminated, most of them genuine bugs, which massively improved the reliability of the program.
Then v6 came out, and code we had introduced to suppress a warning at level 3 triggered its own warning at level 4 :-( The problem is we used a library, to which we passed a bunch of callback functions, and this is what was producing the warnings so we couldn't fix it.
Which is why, when I set programming standards for some end users (who did a little maintenance programming as part of their job) the standard merely said "all warnings must be eliminated or explained away". Annoying, I would much rather have gotten rid of them completely, but I didn't know how.
Cheers,
Posted Sep 19, 2014 12:17 UTC (Fri)
by man_ls (guest, #15091)
[Link]
Going through the list of warnings and deciding which are needed and which are ill-conceived, unnecessary or simply not practical is a painful but necessary task in most environments. As satisfying as turning all warnings on can be, sometimes the warnings are poorly thought. Other times you just cannot afford to deal with all the false positives or reformat all the code just to keep that box checked.
Since these days I write mostly JavaScript (and I love it, please don't hurt me), I am thinking particularly of JSLint and its set of always-on, not always sane, obnoxious warnings. Luckily there is JSHint which takes a more mature stance on warnings.
Posted Sep 19, 2014 9:52 UTC (Fri)
by moltonel (guest, #45207)
[Link]
Turning on extra warnings is a good thing, permanently treating warnings as errors is almost never a good idea. -Werror is great when you're on a warning-busting session and need to cut down the flood.
Aside from pointlessly slowing down the prototyping phase, -Werror is pretty much garanteed to break when your compiler and/or environement changes. For that reason, it's a pet peeve of distribution packagers. Some warnings also cannot/shoudln't be fixed, either because it is a false-positive or for things like a deprecation warning when you still have to support the old environement.
Safety features
Wol
Agreed.
Safety features
Safety features