Rage: Warnings Do Not Stop Me

For an explanation of what a rage is please see the first Rage post. If you do not mind learning as you go then just continue.

Beef:
Warnings do not stop me! Some may think that is a pretty bad ass statement. Someone who lives by that mantra may see a traffic light turn yellow and gun it. They may also be told "NO" when advancing on a woman/man, but still go in for the smooch. Pure bad assess, that is until they get hit by oncoming traffic or slapped and issued a restraining order.

When it comes to programming and living life, warnings should not be taken lightly. Yes I know that with each revision of your favourite compiler you have to deal with more and more of these warnings. These are usually in response to a common problem that is happening in your language so suck it up and resolve them. I am not just talking about compiler warnings either.

You will also get warnings and errors that might not crash your program in the log. READ THEM! REMOVE THEM! The developers of the systems you use in your game took the time to inform you of edge cases you may be causing. Take heed, or there may be consequences later (someone might write about it in a blog).
I can not count how many times heeding a warning has saved my ass. Yeah most of the time that silly signed/unsigned mismatch may be no big deal and you just need to throw in a quick static cast. Sometimes you will find that unsigned variable is actually being set to a negative value which causes an underflow. No one wants that do they? I think not.

Now Raging is not something that just happens, there are certain events that fuel this rage.

Fuel:
Oh my god, where do I start? I see this everywhere. In college it was an epidemic I refused to become a part of. When you are just learning a new language warnings should be addressed even more so. When you kinda know what you are doing, warnings will save your ass even more. In college it was easy to keep the warnings at bay because a lot of the time all your code was made from you.

Warnings in the work place are even worse (for me at least). When I started my first job I had gained huge amounts of code to be responsible for, most of which was not created by me. It also seemed that warnings were not a huge deal to be left in. It did not help that a lot of the code was developed back in the days of GCC2 or earlier. Currently using GCC4 has introduced even more great warnings. One could easily drown in the sea of warnings.

This was terrible. If you needed to track down an issues at a low level you had to basically ignore all the warnings to focus on the issues. That fact was a terrible situation. Warnings should help you, but somehow the low level code base had gotten to a state where they were constant distractions. I had to force myself to not address them in fear of toppling the stack of cards over a 100 games lived atop of.

Error/Warning print outs were even worse. "Failed to get object X", "Unable to release object X", and the list goes on. In a development environment where error checking is important we chose the route of kindly informing the developer of errors and recovering (if possible) without crashing. This was because unexpected errors could happen in the field and instead of crashing over some corrupt data we would rather the player keep playing (given the issue was not severe enough). SIDE NOTE: I work on coin op games so if the game crashes it causes a reboot of the machine, which directly affects coin drop.

Unfortunately informing the developer of an error without crashing is not a good enough incentive for fixing the issues (for some). FIX IT! READ THE LOG! "Hmmmm failed to release an object eh'? ...well it didn't crash so it must not be too serious." Wow, thanks for possibly leaking memory, you are bad ass (sarcasm).

Resolution:
Here is a summary of the screaming text which is a resolution. READ THEM! REMOVE THEM! FIX IT! READ THE LOG! Seriously though this is an issue. If you do not address the warnings and print outs some one will have to eventually. It does not look too hot if someone has to go through your code and do it due to a bug down the line. They will be the one that looks good while you look the opposite.

It only takes a few extra minutes of your time to keep your stuff clean and concise. Not heeding to this Rage could also be a tell tale sign of your code quality as well. If you do not take the time to do this important task do you take the time to make sure what you are writing is the correct solution? Do you unit test and take the time to check edge cases? Do you make sure your code is as optimized as it should? Well lets save those questions for another rage. Brutal Legend next week!