There was once a time where I did not care about compiler warnings, but times have changed. In fact, I remember having a debate with a fellow developer some time ago about why compiler warnings were not that bad..... Oh how times have changed.
In my opinion (my changed opinion) compiler warnings are just a symptom of a bigger problem. When you really stop to look at the warnings you will see that most of the time they are trash left over from development tasks of yesterday.
Lets take a look at some common warnings.
- The private field 'object.property' is never used
This is trash with a capital T. This means some developer once used/need/thought they needed a field or property and turns out they were wrong.
Why is this trash, simple. What happens when some new developer comes along and sees the field/property and thinks 'hey, this is exactly what I was looking for'. But what he (could be she, but I choose he) does not realize is that the field/property is NEVER being used. this can cause all sorts of headaches for him. If the property was not there, he would have to think more and fully understand what he was implementing and thus allowing for his time to be better spent.
Make sure you delete any unused fields/properties as it will save time and headaches.
- The variable xxx is declared, but never used
This is also trash. This is very similar to the 'field never used' warning above.
Make sure you delete any unused fields/properties as it will save time and headaches.
- The private variable xxx is assigned, but never used.
This tells me that someone thought they were going to do something with a value, but decided not to. Chances are that this variable is not even needed and is just wasted code.
Remove these or make sure they are being used.
- The using directive for 'some namespace here' appeared previously in the namespace
This is not a major issue, just says someone added the same statement multiple times. Remove the duplicate.
Remove this as it makes for less code and is cleaner.
- Object.Method is obsolete, it has been replaced by AnotherObject.Method
This can become a major issue down the road. Typically methods are marked obsolete for a reason. That reason may be because the intent has changed or because it is no longer supported.
Now I know that there are times where you still need/want to call obsolete methods, but try to keep this to a minimum. And for goodness sake COMMENT WHY you are using the obsolete method so the next poor sap is informed.
Swap the code out for the newer, non-obsolete methods if at all possible.
I know there are more possible compiler warning messages, but you get the point. Plus I was tired of scanning through the 500+ warnings in our current application.
You may be asking, why the current rant. Well I will tell you. Today I have spent a large amount of time trying to figure out why in the hell our application will not compile. The error that is being spit out is odd, and not very descriptive (not a syntax issue :(). So I decided to start walking through all the warnings to see if something stood out. Well, because we have 500+ warnings, it was very, very pain full. I was able to find the 'problem' warning, and once I resolved that issue, things started rolling a lot better.
One rule of thumb I think every team should strive for is to have as little compiler warnings as possible. I know and understand that it may not be practical to remove ALL warnings, but having a goal to keep the number as low as possible is great.
***** NOTE *****
A lot of these warnings above can be detected with tools like Resharper and thus be easily avoided.
Till next time,