Keyvan Nayyeri

Debugging is one of the most important yet effective stages of software development, especially when it comes to large scale applications. There are many resources about general debugging topics, concepts, and techniques available out there as well as some that specialize on some software platforms such as the .NET Framework, but debugging, by nature, is something that mandates a level of experience, attention, and knowledge. The processes of catching a defect, finding the real reason, and finding the relevant fix (without generating new bugs) in the best form is not as easy as many developers think about it at the first glance.

By the way, there are lots of guidelines written to help developers debug their code efficiency. One of the main facets of these guidelines is, focusing on the symptoms before the defect.

This group of guidelines leave some notes for developers to follow some steps to improve their level of attention to the code and development. Here I just want to focus on one of them which is, treating compiler warnings as errors and not ignoring them.

As you would know (or you’ll know in a moment), almost all the modern compilers for programming languages support a debugging option to treat warnings as errors. Modern languages provide three major groups of compilation results:

• Success: Discussing the obvious?!
• Warning: The difficult description is for this type because I cannot find a comprehensive definition for a compiler warning as it includes a wide range of cases, but in a nutshell I can say that a warning is a suspicious case in the code that doesn’t necessarily yield a generic problem in your compilation or runtime but it can have special side-effects or future problems.
• Error: Obviously, an error doesn’t allow a program to run in a generic form, and application (especially the part of application that throws the error) cannot run.

Like all the other modern software development platforms, the .NET Framework offers the option to manipulate debugger options for different programming languages such as C# or Visual Basic. One of these options is the capability to treat all warnings as errors, stop the application from running, and enforce the developer to fix these warnings. Developers are also able to set a list of specific warning types to be treated as error and leave others as are.

Such options are available in your project properties in Visual Studio and under Build section. Likewise, you can set such options in command prompt when compiling your applications by hand.

But the more important point is the usage of these options in the .NET Framework or other technologies. Many advanced debugging resources strongly recommend developers to treat warnings as errors, and fix them immediately. While this is a very well-known and solid recommendation, still many developers don’t care about it in their applications, and usually leave warnings as are without any treatment.

In my honest opinion this option should be used in all professional applications by developers even in smaller ones, and there shouldn’t be any compiler warning remained in a code that is going to be served on production in a professional level.

For a professional software, some points are very important such as the resource usage, optimization, and scalability. Interestingly, many of the compiler warnings in the .NET Framework and other technologies are those that relate to some misusages of variable definition or usage of obsolete APIs. These are some factors that may have an important impact on resource allocation and optimization of the software.

Some of the compiler warnings caution you about some wrong coding definitions such as definition of a variable that is not used. Obviously such warnings are saving you from an allocation that doesn’t add anything to this world, so it can help your code performance as well.

Other group of compiler errors target the usage of obsolete API or wrong usage of API. Usually new APIs are designed to bring a better performance and features to the software, so usage of the new API can help the optimization of your software very well. Likewise, misuse of API can reduce their quality and may increase their resource usage.

As a direct result of staying up to date with the most recent API, you can improve the scalability of your software as well. The more you keep your code older, the less you can scale it up.

There are many other groups of compiler warnings that can be argued to be worth the treatment that I don’t step in their details here; therefore, I think that compiler warnings must be considered identical to compiler errors for a professional developer.

In summary, the best practice is to treat all warnings as errors and resolve them like an error regardless of any other parameter that may encourage you to not do this like laziness!