Warnings? We Don’t Need No Stinking Warnings


I have been playing with the latest builds of Visual Studio 2005 over the past few weeks but it has been mostly playing with new development of samples and demos.  Today I spent some time upgrading some code I had written in Visual Basic 2003 before I joined Microsoft.  I took a working application and opened it in 2005 to see what it took.


This is an application that is in production and used to run a multi-million dollar business so it as real world of a test as you can get.  Like lots of application this was built with lots of requirements and not a lot of time.  It has a Smart Client UI and Web UI that talk to a core set of Web Services.  These services go to a backend SQL database.


When I first opened the application and converted I had about 100 warning and errors, mostly all were warnings.  This was a bit of a sticker shock and I was preparing for some pain, however after taking a deep breath I looked at the warnings.


Currently there is a debate going on internally about what to show on upgraded projects and what not to show.  Fixing the warning are not required to compile and continue running your application just as it does today, however doing so gives developers a better application.  This is weighed against the problem of having someone open an application in VB 2005 see a large number of warnings and walk away thinking they have to much work to migrate.  Perception is reality and less experienced developer might not understand or take the time to actually read and think about the warnings just simply see a long list.


Most of the warnings where deprecated APIs and objects, since I used the same objects at lots of places in my code that run the count way up.  A few simple global search and replaces and the count had come way down, to about 25.  Over 75% killed in less than 2 minutes.


Digging into the remaining 25 took a bit more time as there was some truth to these warnings.  Since these are just compiler warnings I could compile my application and run it just like it runs today with no problems.  However I found that as I worked these errors it was often little things that were missed during developer by mistake that was causing the warnings.  The VB 2003 compiler was not smart enough to help me out and tell me about these mistakes in my code so I never know they were there. 


For example the warning:


Function 'FunctionName' doesn't return a value on all code paths. A null reference exception could occur at run time when the result is used.


I had a few of these.  Often what had happened was the function was modified by me or someone else over time and there were ways out of the function that did not return a value.  All of these where obscure paths through the code and where never picked up in test.  These errors may have been seen in production and written off by the user as hiccups in the application since they would occur seeming “randomly” and only ever so often.


At end of the day it took about 30 minutes to upgrade my application (Smart Client Project, Web Service Project and ASP.NET project) from 2003 to 2005.  In the end the results of working the warnings were not required to simply recompile and run my application but did result in a much better code base. 


Since this was not a production task that I was doing but a test I will need to send the changes to my former co-workers so they can fix up the 2003 code.


Has anyone else upgrading existing application, what is your experience like?  Do you want the tool to show you the warnings so you can make the improvements (or opt not to) or do you think the developer should be shielded from seeing a massive list of changes they don’t have to make? 


I am interested to hear both experiences from people that have played with Beta 2 and thoughts on people that have not but will be moving in the future.


Comments (10)

  1. Andy B says:

    Nearly all the warnings are relevant and I take time going through them, as I imagine most developers would as they would want to ship good code.

    Though there is a very annoying one in vb2005 which keeps coming up saying you have not initialised an object before referencing it, but it brings this warning up on the line where I am testing to see if the object has been intialised…oh well. I wish I could turn it off the single instances I believe it is not relevant for.

    I believe tackling the warning messages produces better code and I think some of the warning messages should actually be compiler errors.

    In upgrading to beta 2, our main problems were the breaking changes. We found 3 that we had to fix the code for or work around, 2 of which were undocumented.

  2. Quentin Pouplard says:

    I recently upgraded one of my project from 2003 to 2005.

    It’s a winforms based applicaton.

    Most of the warning were deprecated API. That would be very great to get some way to fix those error "automatically", a bit like Eclipse IDE does: propose a quick fix and some ways to apply them.

    On the other side: good points, my app still works! and runtime check (like cross threading call) now generate an exception… I had the opportunity to debug lot of things.

  3. I want the warnings, but I’m an experienced developer. Over 12 years of VB and .NET since original beta 1. I appreciate anything that helps me find mistakes or possible problems in my code. I can see that it might be intimidating to others who are less experienced, but I can’t stand any attempt to "dumb down" the IDE for VB developers. I suppose it could be some developer configured option somewhere or the warnings could all collapse by default like a tree view, but please don’t make it hard to find the warnings.

  4. rockybooth@hotmail.com says:

    I like the warnings. I still have one foot in VB6 as I never liked the first VB.Net and VBnet03 did address the deficits. However, I really do like VB2005, especially beta2. I treat the warnings as options to address, and usually rush past to see if the app will work. Then I go back and study the warnings as a learning tool and feel that they all must be addressed before releasing the software.

  5. Nere says:

    I love the warnings, they really help to find problems in the code. I have converted a bigger internal application and had 3 errors and about 200 warnings after the conversion. The errors were simple to correct, and the application runs. No need to rush an try to get to 0 warnings.

  6. Ken Pergola says:

    Hello Brad,

    I think the best way to please all end-users (or at least try to) is to put the power of choice directly in their hands.

    Maybe the default option should be to show all warnings initially, but let the user easily override this as he/she see fit and make it a "sticky" setting.

    If you make a firm decision at Microsoft to implement the "display warnings" functionality only one way without letting the end-user have a choice, it probably might create more work in the long run for Microsoft since many customers will not have the functionality implemented their way.

    Best regards,

    Ken Pergola

  7. Luis Vazquez says:

    I have upgraded a few small apps to 2005. I think if the IDE would create a list of warnings as a task list after the prossess is complete that would be a nice way to present the changes that I will want to consider.

  8. Daniel Moth says:

    Not only do I want warnings, I actually turn on "treat all warnings as errors". So far I have not come up across a false positive and eliminating a warning has always resulted in "improving" my code. The only exception which I turn off is the possible_nullreferencewarning" which you guys should have simply left out (like any other incomplete feature).

    http://www.danielmoth.com/Blog/2005/05/nowarn-or-vb-compiler-options.html

Skip to main content