Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
5  
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

9 Answers 9

up vote 16 down vote accepted

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).

share|improve this answer
4  
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.

share|improve this answer
    
I definitely agree! –  the Tin Man Nov 6 '10 at 19:02
3  
I agree. OP: you should read about 'broken windows' as decribed in Pragmatic Programmer. –  rmx Nov 7 '10 at 10:54
    
media.pragprog.com/articles/sep_02_zerotol.pdf –  user1249 Nov 12 '10 at 8:35

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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 at 4:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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