The project I'm currently working on generates 30+ warnings each time it gets build. They were ignored from the beginning of the projects. I guess due to the lack of policy about warnings.
How do you usually handle this? Ignore them altogether? Try to fix them all at once (this requires some time)? Or just fix bit by bit along the way?
What I actually do: My current project also generates 30-40 warnings, and I ignore them.
What I should do: Fix them, because some of them might be meaningful.
Best practices are to fix them all together. You should fix the ones that you have now, it may seem like it will take some time but they are usually little syntax errors that can be fixed easily. Then when you start getting them when you create more code you can just fix the ones that come up as you go.
I also always keep my projects on warning level 4, which is the highest level of warnings, so that when i compile i can fix everything that the default compiler (visual studios) thinks is wrong.
In our development team, each person needs to clean up their warnings before beer o'clock on Friday. If you do not fix your warnings - no beer for you. It is surprisingly a good motivator.
I highly recommend building with the setting to treat warnings as errors. This will cause the project to stop building, of course, but it's the only way to enforce a reasonable error policy.
Once you've done that, you can examine the warnings you have and make some reasonable decisions. There are probably some warnings that are benign and which you don't care about, so add these to the list of warnings to ignore. Fix the rest of them. If you don't have time to fix them all now, add a #pragma (or the C# equiv) to ignore the specific warnings that occur in every file, and file a bug for each of these to make sure they are addressed later.
Programmer smoking
A guy is standing on the corner of the street smoking one cigarette after another. A lady walking by notices him and says
“Hey, don’t you know that those things can kill you? I mean, didn’t you see the giant warning on the box?!”
“That’s OK” says the guy, puffing casually “I’m a computer programmer”
“So? What’s that got to do with anything?”
“We don’t care about warnings. We only care about errors.”
;)
My suggestion is ignore until you get the solution working perfectly. Then move to fixing the warnings; since the industry is "Deadline oriented" in most cases.;)
I also think, you should fix them all together and after this i recommend you to switch the compiler setting to treat all warnings as errors.
Most programmers build their code regularly after writing each construct, just to see if it builds correctly. This is the time when warnings are flagged (in VB, they are flagged by the background build as well).
I make it a policy to fix warnings at each build. I also do not accept any code from my team that flags warnings. Only very few kinds of warnings are "acceptable".
So, my policy is that rather than fixing them all together at a later point, I fix them as they are flagged. As a side note, when my code starts flagging warnings, I chide myself for writing code that doesn't meet my standards.
Just imagine your project is a car.
What would you do if any time you start your car 30-40 warning lamps are blinking?
If your build script is giving warning you must at least look what is going on, why is this warning there. Of course that you can have examples of running systems with warnings but this is not what you want (I expect).
We use some static code analyzers lime PMD or findBugs (both for Java). After every build we fix also the warnings delivered by these tools.
If your warning is unimportant for whatever reason then look if your language provides such things like @supressWarning. Actually this is not a recommendation. It is only a comment.
Each and every warning should be fixed, or specifically disabled (using a compiler directive or a code construct that eliminates it).
If you decide to ignore a warning without disabling it, all warnings become meaningless - because you just don't look at them any more. You know that there are some "okay" warnings, so why bother looking at the list at all?
Plus, it is highly recommended to compile at the highest warning level, and "treat warnings as errors" (however this is done by your compiler). If your compiler doesn't support this setting - try to enforce it anyway by looking at its output / returned value as part of the build script/process.
Last fall I inheritied a new 5,000 line Java subsystem that had 100 ignored warnings. Like the other respondents here, my policy is to fix every warning, and in doing so, I found that three of the 100 were true programming errors. Warnings are there for a reason, so don't ignore them, fix them.
While programming you'll encouter so much problems, which won't be capture by compile-time (the evil run-time errors). So the compiler isn't capable to find all problems (aka errors). In some case he just says, mmmh there could be a problem, but i don't really know, please check it (aka warning). So take a look at the warning, fix it and proceed.
In some rare cases you really know what you do and just think, i know this warning, but this code is correct so don't bother me anymore. In these (really rare) cases, you could maybe encapsulate the line(s) which are mentioned with a
// Why you think this warning should be disabled at this point
#pragma warning disable xxx
/// ... some code ...
#pragma warning restore xxx
and proceed and the compiler doesn't mention anymore.
Hence take a look at all warnings and fix them. Either by reprogram it or by temporary disable this warning.
P.S. Really don't disable a warning within your project settings. Cause in this case you would disable it globally (and so maybe for code that will be created in the future) nor you can't add any comment why you disabled it.
There are only 30 of them it's 2 hours work man just fix them.
I completely disagree with anyone who says a deadline supercedes fixing these warnings. You will waste more time churning later on problems in the post code completion stages than if you fixed your problems now. Ignore your manager he probably is a moron who wants to look good to his boss. Initial quality and a correct design is more important than his arbitrary deadlines (within reason). The fact that you have warnings in the first place means that someone was sloppy with the code. Double check the areas where there are warnings exist for correctness.
If you are using code analysis or are writing C/C++ then warnings are sometimes really not valid. In that case pragma them out (C/C++) or System.Diagnostics.CodeAnalysis.SuppressMessage. This can be done automatically from VS2008.
I have not seen any .net warnings that were not valid outside of code analysis.
Code intentionally, grass moker, as though your warnings were rolled out upon trail paper. Fragile as the wings of a butterfly, clinging as the cocoon of a silk-worm -- when you can code its length equivalent of printed warnings, and leave no trace of errors, you will have leaarned. --Master Poh
If the warnings you get are flagging things you hadn't taken into account, you should continue to treat warnings as errors, and fix them immediately.
If the warnings you get are always about things you've done on purpose, and the generated code does what you intend, and the time taken to fix them isn't negligible, you can ignore them, but you'll need a new ritual for fixing errors.
Part of making a fix must now include examining each error, to see if any currently ignored warnings had actually flagged the error. Keep a running count. As long as the ignored warnings wouldn't have helped, continue. If/when you discover you've ignored two meaningful warnings, switch back to treating all warnings as errors. Give yourself some time to improve, then try it again.