I\'ve worked on many projects where I\'ve been given code by others to update. More often than not I compile it and get about 1,000+ compiler warnings. When I see compiler w
I dislike warnings. I remove them as much as possible.
Sometimes, when under pressure to finish the job, i leave some of them. I rarely leave them though. I feel like you, dirty if there are any left.
Leaving warnings in your code because you don't have time to fix them is like not brushing your teeth because you don't have enough time in the morning. It is a basic matter of code hygiene.
My boss who created some code I now maintain. He uses compiler flags to hide his deprication warnings.
When I have time I go through and clean up what I can.
I would clean up any warning. Even the ones that you know are harmless (if such a thing exists) will give a bad impression of you to whoever will compile the code.
It one of the "smelly" signs I would look for if I had to work on someone else code.
If not real errors or potential future issues, it would be a sign of sloppiness
I agree it's best to eliminate all warnings. If you're getting thousands of warnings you should prioritize your fixes.
Start be setting your compiler to the lowest warning level. These warnings should be the most important. When those are fixed, increment your warning level and repeat until you reach the highest warning level. Then set your compile options such that warnings are treated as errors.
If you find a warning that you suspect is safe to ignore, do some research to verify your theory. Only then disable it and only in the most minimal way possible. Most compilers have #pragma
directives that can disable/enable warnings for just a portion of a file. Here's a Visual C++ example:
typedef struct _X * X; // from external header, not 64-bit portable
#pragma warning( push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )
Note that this only disables the warning for a single line of code. Using this method also allows you to do simple text searching of your code in the future to make changes.
Alternatively you can usually disable a particular warning for a single file or for all files. IMHO this is dangerous and should only be a last resort.
Clean them up if possible. On a multi-platform/multi-compiler codebase (I've worked on one that compiled on 7 different OSs with 6 different compilers) that's not always possible though. I've seen cases where the compiler is just wrong (HP-UX aCC on Itanium, I'm looking at you), but that's admittedly rare. As others note, you can disable the warning in such a situation.
Many times what's a warning in this version of the compiler may become an error in the next version (anyone upgrading from gcc 3.x to 4.x should be familiar with that), so clean it up now.
Some compilers will emit really useful warnings that will become problems under certain circumstances -- Visual C++ 2005 and 2008 can warn you about 64-bit issues, which is a HUGE benefit nowadays. If you have any plans to migrate to 64-bit, just cleaning up those kinds of warnings will dramatically reduce your port time.