Thursday, February 07, 2008

Treat Warnings as Errors

This in one of my pet peeves. Its simply none negotiable!


I still don't understand why it can be turned off. Heck, I don't understand why its not turned on by default. I even don't understand why the C# compiler even emits warnings instead of errors in the first place. It seems that I don't understand very much, do I ? ;-)

If you want to know why you should always enable the Treat Warnings as Errors option, then just read this post from Derik Whittaker who just joined the club.

So, let's get to the order of the day, shall we? Stand up, put up your right hand and repeat after me: I will always treat compiler warnings as errors.

Now, to make your life a bit easier, you can use John Robbins' most excellent SettingsMaster add-in which comes with the source code of his book Debugging Microsoft .NET 2.0 Applications (if you don't own a copy of this book, then go get one; you are missing out). This particular add-in adds a button to the toolbar of Visual Studio. Just select a project in the Solution Explorer and press the button. That's it. Your set to go.

Push the button

Make it a habit to push that button every time you add a new project to your solution. It will save you a lot of grief in the long run. Trust me, I know. As usual, I found out the hard way.  


Yves Hanoulle said...

I agree it shoudl be turned on by default. I do understand why it can be turend of, or at least ignore certain errors.
F ex, when you use a third party component that throws errors.
Because C# itself behaves sometimes strange (like in some Case structures)
Or in some unit tests.
But I agree that in 99.9% of teh cases it should be on

Tim said...

Well, one reason I can imagine is importing existing projects with large amounts of old code and suddenly being forced to change them all when you want to be able to use new functionality without spending potentially lots of $$$ to fix everything.

Bryce said...


The link even says "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."

This needs to notify devs to eventually remove their code supported deprecated methods. You can't just remove the method and break the build.