Blog

When learning how to write software, one of the first bad habits people tend to develop is to ignore compiler warnings. This is understandable since the warnings tend to be numerous and tedious, particularly to an inexperienced developer. Compounding this behavior is the fact that – despite profuse warnings – the code will still build, and often times appear to run correctly. So if the project runs what’s the point in going back and silencing the warnings?

The answer lies in an incorrect assumption. The code may run correctly, but only in the exact same circumstances that you have tested. You tested with lots of different values and didn’t find any problems, but that doesn’t mean that your code will only ever see valid input.

Ultimately, all input originates from human beings and, as a consequence, somewhere along the way your code will have to deal with data that is wildly invalid or even malicious.

Unless your project is just a few lines of code it’s simply not feasible to empirically test every possible input combination. Instead, computer scientists built warnings into the compilers to help us catch common errors before they cause problems in data.

Warnings encourage solid design practices and discourage sloppy code. But these warnings do no good if you simply ignore them.

They may seem obtuse and often times will appear too general to be of any use. In fact, there are plenty of cases where a warning doesn’t necessarily indicate that something needs to change. But you should always understand what the warning is telling you. Only then can you make an informed decision as to whether or not you need to adjust your code or suppress the warning.

Understanding warnings – and what they are telling you – is the first step on the road from blindly hoping your code will work to deliberately designing functional systems. Work on making this a good habit right from the start and it will save you countless hours of bug chasing over your career.