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
Always clean up your warnings. If you have a specific case where you know the warning is ok, then suppress it for that instance only.
While some warnings can be benign, most signify a real problem with the code.
If you don't clean up all of your warnings then the warning list will continue to grow and the real problem cases will be lost in a sea of warning noise.
At my work, the compiler setting to treat warnings as errors is turned on. So, no warnings, or it won't compile :)
I always enable all warnings, and then set my project to stop building if there are any warnings.
If there are warnings, then you need to check each one to ensure that there is no problem. Doing this over and over is a waste of time. Not doing this implies will lead to errors creeping into your code.
There are ways to remove a warning (e.g. #pragma argsused).
Let the compiler do the work.
Clean 'em up, even if they don't indicate a real problem. Otherwise, if a warning that does indicate a real problem shows up, you won't see it through all the noise.
One of the characteristics of a really good programmer is that bad code gives them a queasy stomach.
I strive to have all of my code not only compiler clean, but also be clean inside my IDE set to a fairly picky level. I'll sometimes need to suppress a warning instance if I know better than the tool, but at least that also serves as documentation.
The codebase I work on has over 4000 warnings. Some of them are legit problems. We never are given time to go in and fix them, nor refactor other broken things... Partly, this is because the code is so old it predates standardized C++. We can only compile in VC++ 6.