improving your code by fixing warnings

I don't know why, but there is a class of software programmer who seem to believe that compiler and runtime warnings are somehow optional, or something that can be cleaned up at a later date. This class of programmer is very common in the commercial software world.

I've never really been sure why people think these warnings can be ignored. Compilers are pretty smart these days, and if a the compiler says you have a type-mismatch for your pointer assignment… there's a good chance you did something silly.

Library developers don't just add all of those pesky assertions to their methods for fun. If your code is outputting critical warnings, you probably shouldn't be surprised that it's crashing shortly afterwards. Something clearly went wrong.

So what can you do? Compiling your code with warnings-as-errors when developing it is a very good step (-Werror in gcc). For runtime warnings, you can probably set an environment variable to make the program abort when reached (e.g. for GLib you can export G_DEBUG=fatal-warnings or fatal-criticals) — this allows you to attach a debugger when the warning is reached.

Simple steps for much better code.

This entry was posted in best practice, listen to your tools, programming, work. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>