My modis operandi is to treat warnings as errors. Warnings frequently become errors if ignored.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Starting from scratch this is what I do. But most of the time I'm inheriting a team codebase and fixing them after the fact is usually not an option. It would need buy-in from the management. "Pause, fix all warnings and retest everything."
Of course, if these occur in an area of code I happen to be fixing or enhancing then it's another matter.
Intel's Visual Studio compiler warnings and error messages are so vague that all you learn is that something is wrong. They are so miss leading that they cause you to go on a wild goose chase instead of finding a successful solution.
Warnings are important - they generally mean you made a mistake that could affect you later when you have forgotten all about it.
Fix 'em all.
Yes, it does annoy me when I get errors like:
CS1591 "Missing XML comment for publicly visible type or member ..."
CS0219 "The variable 'x' is assigned but its value is never used"
But not as much as having to revisit code to add XML documentation later when I've forgotten it, or find I used the wrong variable in debugging ...
Generally, compiler warnings these days are sensible: ignore them at your peril! And certainly, if you are a beginner, warnings indicate you did make a big mistake and have to be looked at before you run your code.
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
What (s)he said. Very often the answers are difficult to choose from because some "common sense" answers are not there(not that I'm knocking anyones common sense, it's just that this weeks is a case in point, it should have had a "fix errors and as many warnings as possible" answer).
#pragma warning disable IDE0060 // Remove unused parameter
// In this example the offending parameter goes here.// Useful if some interface gives you a parameter you don't use.#pragma warning restore IDE0060 // Remove unused parameter
That works in C# at least, I'm guessing your language (if not C#) has something similar.
I fix messages, warnings and errors.
If someone else checked them in on an otherwise clean solution I'll talk to them about it and (hopefully) get it fixed.
When there's an existing solution with many warnings already I can't be bothered, or when the team obviously doesn't care about them and it seems to be a lost battle.
I don't get it though.
Here's your compiler telling you your software may have issues.
Why don't you just fix it and keep your code clean
Although I once left a comment in some code along the lines of …
//The line above this comment must be blank to avoid a bug in the [name of product] pre-compiler.// If you remove the blank line at the top of this header I will find you // and I will break every bone in all of your fingers. One by one. Slowly. [my name and extension number]
I tend to avoid any warning in my code (though I have de-activated a few, such as the 255 mentioned above). But my co-worker are not so single-minded and I have to remind them on occasions. May be if I had the right to terminate them that could change things!
...at the results of the poll so far.. I honestly expected option 1 to be the clear leader.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013