Make it a warning!!!

My code samples of the past couple of days have led to a few requests for warnings, which reminds me of a story. So gather round old Grandpa Gunnerson. Like many such stories, this is something I’ve said before – probably on this very blog – but I can’t find anything through search, so you’ll have to bear with me if you’ve heard it before, and when I’m done, we’ll all go out for ice cream.

Back in the previous century, I worked on the VC++ compiler team as a test lead. Given the amount of rope you have in the C++ language, we spent some time one release talking about adding some new warnings to the language for questionable behavior, and ended up adding a few. Because of the nature of the language and the warnings, they were 50/50 things – about half the time the warning was useful, and the other half it wasn’t. Because lots of users compile with “warn as error” turned on, we had to put them at a high warning level (level 3 or 4).

Which meant that 98% of our users never benefitted from the warning. In other words, we were just wasting our time.

We stopped adding level 3 or 4 warnings at that point.

Thankfully, C# has much less of a problem in this arena, but there are still some tricky areas, and we considered warnings for them. But we ended up implementing very few, since there is nothing more annoying then getting warnings that you have no way of shutting off, or (in V2), where you have to modify your code just to shut the compiler up.

If it’s dangerous, you should consider whether it should be removed from the language or made more explicit. If it’s not dangerous but more in the advisory vein, it belongs in a tool like FXCop.

Now somebody find me my teeth, and we’ll be going…

Comments (5)

  1. Gavin Greig says:

    For what it’s worth, there are some of us out here who turn warnings up to 4 and turn on warnings as errors too, so it’s not wasted effort.

    It’s nice to think we might be top 2% developers, but I doubt that’s actually the case.

  2. Chris Nahr says:

    I just wish that C# 2.0 wouldn’t warn about ambiguous method references in XML comment tags where the target method is overloaded (0419). That’s perfectly valid when one intends to reference a family of overloads, rather than a specific one. The default action (linking to the first overload) is fine, too. What’s there to warn about?

  3. Matt says:

    Yes I admit that I hadn’t thought about the fact that you cannot use an explicit new to at least make it clear on reading class B that it was doing something possibly unpleasant, thus obviating the warning.

    prob doesn’t justify a new ‘new’ keyword ‘maybenew’ or ‘potentialshadow’ 🙂

  4. Miral says:

    I’d rather have tons and tons of warnings, but be able to invidually (and temporarily) disable them at the line-of-code level. That’s the best of both worlds — you get told about anything suspicious, but you can make it go away once you’ve confirmed that it’s ok in that situation.

    AND you have a bit of implicit documentation there so that later on if a bug crops up in that bit of code you can look at it and see "oh, we disabled a warning there — maybe it really WAS a problem after all".

    Especially since in VS2005 it seems to be more difficult to get hold of FxCop.

  5. michkap says:

    Warnings have their own dangers if one does not keep on top of them….