Many compilers have warning messages to warn the programmers about potential runtime, logic and performance errors, most times, you quickly fix them, but what about unfixable warnings?

How do you deal with unfixable warnings? Do you re-write a portion of the code, or rewrite it in the "long, hackless way" or disable warnings all together? What should be the best practice?

What if you are editing someone else's code and his code has warnings?

Here is a good example: jQuery has a lots of JavaScript warnings as a Mozilla-class browser detected, why the jQ developers don't fix them? If you contribute to jQuery, are you going to fix them?

  • 7
    Can you give an example of an unfixable warning? – Note to self - think of a name Nov 6 '10 at 18:20
  • 1
    A warning by definition is a warning. Therefore it doesn't have to be "fixed". So what is an unfixable warning? – Rook Nov 6 '10 at 18:49
  • Using generic types in Java often generates a warning. The only way to "fix" it is to add @Suppress, which isn't very clean, IMO. – Michael K Nov 8 '10 at 1:26

10 Answers 10


Some warning are usually safe to ignore but if you do so then over time they'll multiply until that day comes when there are so many that you miss the one warning that really matters because it's hidden in the noise.

Fix warnings immediately (which may include disabling individual rules if you feel that it's never relevant for your context).

  • 8
    This. I've inherited code bases with decent-sized collections of warnings; none of them are warnings for anything that I particularly care about, but what I do care about is being able to see the brand new "0 error(s), 1 warning(s)" when I do something wrong. – Carson63000 Nov 8 '10 at 0:28

My opinion is that you should be strict with yourself. The compiler has been written by total experts in the language. If they are reporting that something is a bit wiffy (think code smell) then the code should be reviewed.

It is entirely possible to write code that compiles without errors and without warnings.


When I was writing in C and C++ I'd enable the strictest settings I could because I wanted to know when something wasn't making sense to the compiler. When I was done casting and checking return values I'd be happy because the code was as correct as I could make it.

I'd occasionally get code from someone else that would spew warnings. Checking the source showed they were ignoring things that were good programming practice in C, making their code fragile.

So, I think there are good reasons to enable strictness and take the time to fix things. Doing otherwise is sloppy. If I had a co-worker who turned off warnings I'd spend some time with them AND the manager explaining why that is a really bad thing.


I would fix any warning. If you ignore them and let them accumulate, you might actually missed something important.


Generally you should strive towards making the compiler silent, so that new warnings show out more. These warnings may indicate subtle bugs and should be handled accordingly.

Regarding fixing other peoples code, it strongly depends on both your workplace culture and the current state of the code. You cannot just alter code if it triggers a complete retesting cycle, like it would for code late in the test phase or in production.

Ask your boss, and act accordingly.


Every time you see a compiler warning, you have to stop and think about whether it is really a problem waiting to blow up in your face at the customer's site, or something you can ignore. Worse, the things you can ignore TODAY may be things that will blow up at the customer's site in a few years, after a seemingly-unrelated code change Somewhere Else.

Fix the warnings. Period. It is that or document every single one of them, with as many pages of explanation as is necessary to prove it isn't a risk, accompanied by a signed sales order on your favorite girlfriend (or porn stash) if it turns out that it WAS a risk.


Generally, you want your build to be warning free. Warnings are there for a reason, and often they do point to very real problems. If you get into a habit of ignoring compiler warnings, then eventually your build will have a ton of them, and you will miss the one warning that is caused by a catastrophic problem that will cost your company dearly. On the other hand, if your program normally compiles without warnings, then every new warning is immediately noticed, and can be quickly addressed.

Having said that, sometimes compilers can have warnings that make little sense and which cannot be easily fixed. I face this situation every day at work with TI CodeComposer, which is a development environment for TI DSPs. I have C++ code that compiles with no warnings under Visual Studio, but which results in strange warnings in CodeComposer, simply because TI's support for standard C++ could be better. Luckily, CodeComposer lets you disable specific warnings individually, which is what we have to do when there is no way to fix the code that produces the warning.


In my case warnings come from the PyLint tool and I can disable a warning on a particular line by adding special text in the comments.

In most cases, I don't do that. In most cases I change the code to follow what PyLint suggests because PyLint is usually correct. However, in dislikes constructs which are generally a bad idea, but which make sense in a particular context. For example, it complains if I catch all possible exceptions. Usually, its correct, that would be a bad idea. However, in some cases I do want to catch all exceptions such as to send myself an error report with the details.

So: In almost all cases, get rid of the hacks. When the hack is really justified, add a comment telling PyLint its okay.


Some of the benefits of strictness was not clearly stated in the other answers:

  1. When all the easily fixable warnings have been fixed, the remaining significant/relevant warnings are more likely to show up.
  2. If the relevant warnings are found and dealt with on time (before release), bugs can be avoided, thus leading to better end user satisfaction
  3. Solving the warning usually leads to more maintainable and simpler code (e.g. eliminating conditions that are always true)
  4. When amount of warnings is closer to 0, it is easy to agree on Zero Warnings Policy in the team, that is very easy to automate in CI system.
  5. When solving compiler warnings, understanding of the program code deepens, which may lead to useful insights about the implementation (e.g. discover other bugs or get ideas how to develop the code further)
  6. Build gets faster, daily productivity up: IDE/compiler has less issues to manage and report on, thus compilation is faster (this is only relevant in the context of thousands of warnings).

There are language specific differences on certain kinds of warnings. I think it is important to think and discuss on the topic and then disable some individual warnings if they feel totally useless so that the strictness can be achieved. This has been accomplished in several teams on my career. More on my experiences on the topic


Warnings and errors are messages that the compiler uses to tell the programmer "something you wrote didn't make sense" -- the difference between them is that with a warning, the compiler is willing to make a guess as to the programmer's intentions, whereas with an error, the compiler can't even make a guess.

Compiler errors will get addressed (I'm not going to say fixed), but all too frequently, programmers (even experienced ones) will ignore the warnings. The problem with ignoring the warnings is that sometimes the compiler guesses wrong and if you've got 1000+ warning messages, it's easy to miss a warning message that indicates that the compiler is guessing wrong.

From a sociological standpoint, programs that have many warning messages are Broken Windows.

  • 1
    Not true, lots of compiler warnings are about things that the compiler understands 100% and is not in any state of flux (understood it previously, understands it now, will understand in the future), but is in the experience of the compiler writers, frequently written incorrectly. You are answering a 3+ year old question incorrectly... – jmoreno Apr 20 '14 at 4:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.