The boy is smoking and leaving smoke rings into the air.
The girl gets irritated with the smoke and says to her lover: “Can’t you see the warning written on the cigarettes packet, smoking is injurious to health!”
The boy replies back: “Darling, I am a programmer. We don’t worry about warnings, we only worry about errors.”
Many developers tend to give little attention to writing code that generates no warnings at compile time, thinking that since there are no errors, it’s all good.
However, if the compiler issues a warning, there is a good chance that there really is a not-so-obvious problem hidden in the code. If you dig deeper, you might find issues like 32-bit pointers used on 64-bit architectures, comparisons between signed and unsigned variables, and others alike.
What is more, these real problems will be obscured by the tens of “not important” warnings, and you will most probably miss them.
“Unimportant” warnings
If you come to think about it, why do you get these “unimportant” warnings?
Usually it’s because you forget about a declared variable which you no longer use, leave function parameters unhandled, and so on. Problem is – why live with them? In fact, they only scream to you “Clean the code!!!”. Why wouldn’t you delete a parameter that you’re not using, or why would you keep an unused variable?
#pragma warning(disable …)
You may be tempted to easily prevent the warnings to annoy you by simply disabling them. Well, this “ostrich” approach is one of the worst practices that you might do as a developer.
There is one exception though, specifically when you are using 3rd party modules which are poorly coded and thus generate warnings at compile time. In that case, you really have no fault, there is nothing you can do about them, and it might be a good idea to disable them. Good news is, that you can disable the warnings only for the included header file, by wrapping it with a #pragma warning(push) / #pragma warning(pop) construction:
#pragma warning(push) // disable warnings for this header only
#pragma warning(disable:4213)
#include “header_with_warnings.h”
#pragma warning(pop)
The Bottom Line
Do not treat compiler warnings superficially. Use your compiler at its highest warning level and, if there are warnings that appear when you compile your code, understand them and eliminate them by fixing the code, rather than by disabling them.
Title picture © Les Cunliffe | Dreamstime.com
#1 by Andrei Rinea on September 8, 2008 - 8:14 PM
Quote
“Why wouldn’t you delete a parameter that you’re not using” – I have a Garbage Collector
#2 by alexrosiu on September 20, 2008 - 10:45 AM
Quote
You don’t have a GC in lower level programming languages, which are mostly used when performance (in terms of memory and speed) is the first priority.
But even if you did, it is still preferrable not to waste memory, even if you might be tempted to think that running out of it is almost impossible, thinking of nowadays’ systems’ resources. The software should also run as well as possible on slower, older systems as well. Also, Garbage Collectors are not 100% predictible, which can translate to delayed freeing of unused memory blocks, due to their own internal logic.
Not least, thinking of a commercial product, which is subject to intense user experience, and also (hopefully) to expert reviews, you wouldn’t want it to show high memory usage. What is more, you wouldn’t want it to make a bad impression due to “memory leftovers” that you might have forgotten here and there in the source code.
#3 by Andrei Rinea on September 24, 2008 - 12:45 AM
Quote
There are numerous debates regarding the lazy garbage collection and deterministic memory de-allocation. I won’t start one although I studied for some time the Garbage Collector implementation in Microsoft .NET (which BTW resembles the Java implementation pretty much).
For unmanaged resources (file handles, TCP connections and many others) there is a means of deterministic finalization in the form of the IDisposable interface available.
#4 by Fili on September 29, 2008 - 10:53 PM
Quote
Andrei, sorry but you are wrong. Not even the most intelligent garbage collector can’t help you to get rid of unused variables. The GC gets rid of unused instances. Oh, and you don’t have GC in C++ (ok, you have SmartPointers, but we’re not talking about that
)
#5 by Andrei Rinea on December 1, 2008 - 5:10 PM
Quote
Fili, correct. You have compiler tools that tell you (some even on the fly) when you declare something that you don’t ever use including method parameters.
#6 by Rattier Sebastien on December 13, 2008 - 10:32 AM
Quote
dear all,
Even if you have a Gc that is perfect, it is important to remove useless variable as well as useless code. even if I don’t consider memory usage, that i should…. have useless variable, code makes your code impossible to maintain sooner or later. For a commercial product with a long life, and probably various people working on it, it is unacceptable to let useless code or variable.