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.