I’m going to go out on a limb here to make a point that treating warnings as errors can be a bad thing.  I think there is a place and a time for such requirements.  When code has reached the testing or maintenance part of its life-cycle, treating warnings as errors makes a lot of sense.  It results in higher quality, more accurate code, cleaner build results and possibly a better overall product (though I don’t see how a rogue unused import statement would make any difference when it comes to the perceived quality of the product).

With that said, it has no place in the implementation process.  Instead of a tool for writing better code, it has the ability to manifest itself into a big waste of time and a destroyer of the elusive “flow”.

Recently I’ve been working on a feature that requires communication between a couple of different layers.  In one layer I’ve set up an event listener/dispatcher to listen for events from the other layer.  The dispatcher then calls upon an event processor that does what is needed for each event and passes the results back to the other layer through a callback function.  I created an interface to wrap the callbacks so I can set up a test environment that points to some fake callback functions until the other layer’s actual callbacks are in place.  I then created a variable for the callbacks within the event processor with the intent on using it later, but before that it was to define my class design a little more clearly within the code.

Before getting the callback stuff working, I needed to get the event communication between the two layers working properly.  I spent about an hour working out the details before I attempted to build and see how well I had progressed.  All my syntax seemed fine, thanks to the power of the modern IDE.  So I was pretty sure it would at least compile.  Running properly was a completely different story, but I thought I would at least have a build that I can get on the device and start debugging. I fired off the build and about five to six minutes later…

“You dumb shit. The variable _callback is never used. I could just keep building and let you off with a warning…screw you, bitch. Error!”

Okay, so my compiler isn’t that big of a douche, but it might as well be as it just puked on a warning during a build process that takes around 10 to 15 minutes to complete, depending on what you changed, all because of a variable being unused.  A variable that I expected to be unused at this point as it is just there as a place-holder for me to visually see the design of my future implementation.  Any flow I had going is completely shot at this point, as you might have expected.  There’s nothing else for me to do but let out a sigh, comment out the variable, start the build again and go get some coffee.

When I returned the build had aborted…again!  This time it’s due to a package being imported that isn’t being used; the same package needed for the callback variable that I just commented out.

“Hey idiot, you don’t use this package. Error bitch!”

Now that’s twice the compiler has called me bitch.  Twice!  All I can do is go the rout of Jim Carrey in Liar Liar; piss, moan, bend over, take in tailpipe.  Comment out the import statement, start the build process and make some notes in my notebook to write a post complaining about warning as errors.

So, you can see my point about it being a bad thing.  Anything that decreases your productivity needs to be considered a bad thing.  The question that I’ve been pondering though is, is it worth turning warnings being treated as errors off in my local environment during the implementation stage of a new feature?  Do I dare risk becoming the ass hole that broke the nightly build because I didn’t turn warnings as errors back on before submitting my changes to the depot?  Yeah, that’s all I want is it to be the jerk that thinks he’s better than treating warnings as errors.  I don’t think so.

So, I’m dealing with it.  I’ve made some adjustments in my IDE to make it more obvious that I have potential warnings that will break a build process.  Mainly, I’ve adjusted the color of the squiggly line color from a barely visible whiteish yellow to the blazing red of the error messages.  I’m thinking this might need to change to a different color to avoid me having to decipher whether the marked code is actually an error or a warning, but “you’re freaking screwed” red is fine for now.

I also use a lot of //TODO comments now to layout the skeleton of classes.  It’s not as pretty, but at least the IDE generates a nice task list based on them for me to reference.  All and all I’m still not for treating warnings as errors so early in the development process, but sometimes a slightly less productive setting for yourself can be much better than possibly slamming your whole development team’s productivity against a brick wall.