Every so often I find myself in a heated debate on what the quality bar should be for the code in the solution we are working on. This is an important debate, and for the project's success it should not be down prioritized. The quality bar may vary from project to project: If you are developing an internal tool for your team, you will have a completely different quality bar, than if you where writing software to control a spaceship. So in reality it all depends on the project you are working on. The important thing is to lock down on a quality bar and have all developers buy in and conform.
A part of setting the quality bar for a project is to determine whether to treat warnings as errors. Warnings are an intrinsic part of the tools developers use everyday such as compilers, FXCop, X++ Best Practice Check, PreFast and StyleCop. And for this reason you can have a good, sound, opinionated and often long talk on this fine topic with almost any developer you may cross on your way.
Being a devoted advocate for improving the code quality across any project, I want to share the following general considerations (courtesy of Ryan Harlicker) with you on why to treat warning as errors:
If you are an X++ developer you can learn how to resolve X++ Compiler warnings here.
If you are working on X++ development, but cant' figure out how many X++ Compiler warnings you have, you should read my blog post on AOT Metrics.