Hints and Warnings begone!

This previous post has stirred some interesting comments and reactions (thank you!). I would like to come back on the “no Hint, no Warning policy” and why I like it, but without the need to be zealot.

Why desirable?

The analogy with the “no memory leak” continues here. It is useful beyond its natural object (less bugs, less crashes, better quality, better user experience) for exactly the same reason: some kind of broken window theory.
When you start with a clean slate and if you do continuous integration or simply compile often when writing your code, it is far easier to spot a notification popping out in the open. On the contrary, when you start with hundreds of hints or warnings, you have little chance to detect that you just added a new one in the middle of the crowd.
It is also easier and less a burden to go and fix something in your recent code, than to cope with numerous occurrences of bad old code. Easier to stay clean than to indulge in filth and try to scrub later.

What it means

There are some warnings that you mostly cannot avoid, for instance the Platform warnings as Jolyon rightly pointed out. You may also have some coding guidelines that tend to create hints, like initializing local variables systematically at the top of the routine, even if the value won’t actually be used later, like D Hovden explains.
What I like to do in such cases is to play with the compiler directives like $WARN and $WARNINGS with as restrictive a scope as possible to avoid the notifications. It obviously supposes that the code is indeed correct and there is an explanatory comment.
It is most useful in libraries and components that tend to be reused a lot and somewhat well debugged. Look no further than the VCL.


It makes my life much easier if when I start a project, it shows no hint nor warning… and stays that way when I add my code.

This entry was posted in Coding standard, Delphi, Quality and tagged , , , , , . Bookmark the permalink.

4 Responses to Hints and Warnings begone!

  1. Jim McKeeth says:

    Totally agree with you on the no hints and no warnings policy. If you can’t eliminate them through fixing your code, then use the compiler directives to turn off the specific warnings and hints (like the platform ones.)

    The biggest reason is that if you have warnings you are ignoring, then you will miss the new ones that you need to see when they appear. A combination of broken windows and getting lost in the crowd.

  2. A.Bouchez says:

    Totally agree.
    This is especially important, if you want your code to cross-compile with Unicode and not-Unicode version of Delphi.
    Warnings will tell you most of the implicit StringUnicodeString conversions, which are prone to conversion error (i.e. data loss) and performance issues.
    It could take some time to get it right, if, like us, you use UTF-8 encoding for your data (and therefore request explicit conversion to UnicodeString). But it’s worth the time spent in.
    And I like the fact that you emphasized about the comments needed in the code, every time you disable a warning with the {$WARN} directive. It’s mandatory for code maintainability.

  3. Larry Hengen says:

    I completely agree. Getting rid of all the warnings is usually one of the first things I do when taking on an existing project. It usually gives an excellent indication of the code quality, and fixing the warnings usually results in fixing other “mysterious” bugs in the product before I even get the bug reports. Warnings are just another tool to ensure code correctness.

  4. Lars Fosdal says:

    I also strive for having zero warnings / hints. Otherwise, you might end up missing silly little bugs.

    For work in progress, I usually have a {$hint warn ‘ ——————————–> some warning description’} to make it stand out from other “unintentional” warnings.

Leave a Reply

Your email address will not be published. Required fields are marked *