When building someone else’s software, there’s nothing more demoralizing than seeing whole rafts of compiler warnings fly by. A common reaction to such spewage is, “Are these real issues requiring investigation, or is this just the handiwork of a sloppy developer?” Not all warnings indicate problems with code, but there’s no way to know for certain without actually looking at each and every warning. Needless to say, when warnings turn out to be nothing, it’s downright frustrating — and a huge waste of time. So, professional developers not only work hard to eliminate compiler warnings, they ask the compiler to produce more of them. Why? There are three very good reasons:
When building someone else’s software, there’s nothing more demoralizing than seeing whole rafts of compiler warnings fly by. A common reaction to such spewage is, “Are these real issues requiring investigation, or is this just the handiwork of a sloppy developer?” Not all warnings indicate problems with code, but there’s no way to know for certain without actually looking at each and every warning. Needless to say, when warnings turn out to be nothing, it’s downright frustrating — and a huge waste of time. So, professional developers not only work hard to eliminate compiler warnings, they ask the compiler to produce more of them. Why? There are three very good reasons:
1. Sometimes the extra warnings represent real issues that wouldn’t have been reported by a more lenient set of diagnostics. Never turn down the compiler’s help. It’s the cheapest way to find bugs.
2. By eliminating all warnings, you can’t help but notice when a new warning appears. Otherwise, your build with twenty “Oh, just ignore those” warnings could easily hide a twenty-first warning that’s actually meaningful.
3. When the next person (or perhaps even you, six months from now) builds your code — especially on a different platform — they won’t waste time tracking down “unimportant” warnings from the compiler.
In this month’s column, let’s talk about clean compiles: how to turn on warnings and attend to them properly to produce diagnostic-free (and perhaps even “bug-free”) code. All of the examples here use…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
