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.
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.