Sometimes more is more. That is something Yogi Berra would say. Set and keep the warning level at the highest level. More warnings during compilation are the result. You must then commit to investigating every warning, which is an element of defensive programming. It is better to resolve reported problems early instead of later at run time or during deployment. You should always prefer to find problems before the customer. Fortunately, the default warning level is 4, which is the highest level. Lowering the warning level will assuredly lead to quieter compilations. However, in this circumstance, silence is not golden.
You may also consider treating warnings as errors. This mandates that every warning must be recognized and resolved before a successful compilation. This is important for defensive programming because problems cannot be deferred to later. Current compilers are sophisticated and not prone to generating extraneous warnings. For that reason, no warning is a nuisance and every warning is worth investigating. The Treat Warnings As Errors option enforces this policy. Unfortunately, this option is sometimes not practical for legacy applications, where the challenge to address every warning is not always possible. However, it is important to retain this option as long as possible. Alternatively, you can redline specific warnings using the pragma error warning statement. This would allow the continued use of the Treat Warnings As Errors option, while accepting some warnings.
Set both the Warning Level and Treat Warnings As Errors options in the Project Properties dialog box. In the Properties window, open the Build pane. From there, the Errors And Warnings and Treat Warnings As Errors option groups are available. See 8-1.
