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:

1. They just look bad
   If your consumers are able to run the same tools as you are, and thus detect the same warnings, that you've chosen to ignore, it makes you look sloppy. For X++ code this is the case.
   
2. Most warnings are really the tool reporting an error
   Most of the time a tool reports a warning it is really an error, but the tool cannot prove it. It is then reported as a warning so a human being can verify the issue and take appropriate actions.
   
3. Too many warnings effectively means no warnings at all
   Warnings tend to breed exponentially.  It is best to deal with them at the time of creation as that person has the most context and knowledge of the right thing to do with the warning. If they aren’t handled right away then the knowledge barrier and the fact that they have always been there suppresses the urge to do the right thing and fix them (or suppress them if they are by design).
   
4. They are there for a reason
   The warning detection code in the tools didn't come out of thin air. At some point in time someone felt strongly enough to invest time and money in improving the tool to report a warning. At the very least the reasoning for ignoring them should be well understood and not just ignored because they are a warning and not an error.
   
5. Your project may become successful
   Even when you are working on a project for a small audience with a high level of tolerance for bugs, you may eventually be in a situation where your project evolves and will reach a broader audience. As the quality bar goes up, so does the cost of fixing warnings. Fixing them right away is cheaper than fixing them later.
   
6. Hate to say I told you so!
   Have you ever been debugging a nasty problem for hours, and a split second after you finally reach the Eureka! moment, you realize you were already warned about the problem well in advance? You had just choosen to ignore the warning reported. Personally, I just hate when the tools laugh at me.

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.