Patterns: Always compile with debug tags

99 little bugs in the code

99 little bugs in the code

Take one down, patch it around

117 little bugs in the code

-Alex Shchepetilnikov, Twitter Jul 2013

Experienced programmers have embraced the truth that, as the size of the code increases, the number of bugs increases exponentially. While we do our best to eliminate the most critical bugs (through patterns and careful debugging), we never catch them all.

Anyone who has ever played a modern AAA game can attest to this fact.

Debug tags during development

If you don’t use the debug tag during development, your debugger is useless. Sure, you can still run down the biggest errors by watching the warnings and running the code with varied tests, but you handicap yourself.

It takes all of fifteen seconds to add -g to your makefiles’ default compiler tags. The value you gain by preserving the symbol tables is too great to ignore.

Shipped code

So, you shipped your code. If you’re a giant AAA game company like EA, you might be able to get away with ignoring the vast majority of error reports (because you’re busy raking in money from your annual franchises), but the rest of us take some pride in our release code. More importantly, corporate programs need to work or the company takes on work, risk, and financial liability.

Have you ever tried to run a debugger over code without debug tags? There are no variable names, the registers hold meaningless values, and you will spend more time trying to read the log outputs than you do fixing the problem.

Worse still, if you try to recompile with debug tags, you might eliminate or shift the problem. This means that you will not successfully debug the problem, and you may well introduce new bugs into the code.

This is why it’s valuable to release code with the debug tags intact.

When an error report comes back with all of your (highly detailed) logs, you can quickly recreate the issue in your debugger. Even better, you can set effective breakpoints and manipulate the variables such that you are now able to determine the source of the error and correct it, distributing a quick and (relatively) painless patch to eliminate the issue.

There are exceptions. If we’re dealing with secure code, we do NOT want it to be easy for just anyone to access the internals and modify them. In these cases, we can’t employ this pattern (which means we have to double-down on our log files to make up for it).

 

Lesson: Debugging does not end on release. Maintenance is easier when we leave debug tags available.

Facebook Auto Publish Powered By : XYZScripts.com