VS 2005 warnings

[ASB]

Moving forwards from VS2003 to VS2005 (VB) I have a load of warings to resolve.

Most of these are 'x is used before it has been assigned a value. A null reference exception may result'.

This stem from:-

dim x as someobject

.....
.....

if x is nothing then
.......
end if

Now if I change the declaration to:-

dim x as someobject = nothing

then it's OK.

So, where can I find some guidance on this (stuffed if I can find anything about anything in the help).

It's not a problem being explicit of course, it's just I'd like some background

[AtW]

It's a very good warning and it was present in C# as an error and rightfully so: basically if you just declare a variable without assigning any value to it (even if its null or nothing) means that you are potentially making a mistake that will only become apparent during run-time in some rare case that you won't test - and lets face it very few people create test cases with 100% coverage of code, so there is a very good chance you have got time-bomb on your hands.

You do assume that if variable is declared then it has value of nothing, but for this you need a check if its nothing which you do have, but you might forget it and use variable before that check which will lead to failure.

Bottom line is this: always assign default value to declared variables even if its null or nothing, the only exception to this is when you declare variable and then you have IF/ELSE of some kind that will assign different starting values to that variable, in this case it makes sense not to give default one because it would be waste from performance point of view.

And use C# - all pros do

[Weltchy]

Its been like this in C# for ages m8. Turning off option explicit of course will get rid of the warning, but I'm all for having to explicitly declare and cast my variables, just to ensure I get early binding!!!

As for documentation, I think there's some up on msdn about this referred to in some of their best practises and performance white papers, but I can't be arsed to find them!!!!

On a sidenote, you only just moved to VS2005?

[ASB]

AtW,

Don't have a problem with it, but there are a few quirks. There is an amount of code of the form:-

function a as someobject

if aaaaa
a = new someobject
return
end if

return

This generates a warning not everything returns a value. So I have to add "else return nothing" (or whatever). This is going to cause a performance hit (ok, tiny but...).

Similar problem with "byref" parameters where these are returned by a function. Of course if VB did out parameters....

I'm still trying to get to C#. Hopefully this will happen during the current project because the external developmers want to use C# not VB

Weltchy,

Cheers, I'll try track it down on MSDN when I get a minute. Moved to VS 2005 yesterday

[AtW]

This is another error that compiler helps you catch before it hits some client at run-time when you are on another contract, yes I know this would not have been your problem, but compiler helps create bette software.

Your function needs to return something, but you only do that once in case of successful IF statement - otherwise you effectively return unassigned variable which leads us to the same case as above.

There are no performance penalties in that because some value will always have to be returned so previously compiler behind your back would assign Nothing to it, but now you get warning/error so that you - the programmer - can make correct choice because what the compiler was doing before involved a probability of run-time error down the line.

If the function is small then it is likely to be inlined anyway.

What you need to do is this:

----------------
function a as someobject

if aaaaa
a = new someobject
return
end if

a = Nothing

return
----------------

Looks like cr@p to be fair, here is much better:

object a()
{
return aaaa ? new object() : null;
}

Or, if you are sure that aaaa is most likely true:

object a()
{
if(aaaa)
return new object()

return null;
}

[ASB]

AtW

Strangely the C# doesn't compile in VB

Fact is the real code is somehwat more complex. Also it has been migrated through various people from VB5 ages ago. I personally wouldn't have been inclined to create it the way it is, but I don't have time time to straighten it out properly.

Still, I've dealt with all the warnings, so the process was painless.

[Weltchy]

Get over to C# m8, you know it makes sense!!!!!! I started out as VB, but honestly, I find it an ugly language these days. {} are the way of the future

[ASB]

Hopefully that will happen v. soon. This entire project is part of a large redevelopment, this is just the initial proof - i.e. lash it up and get in running ).

All the VB is to move to C#, so thats the way I'm headed.

[AtW]

There are VB.net converts (and I wrote one in Perl myself - not 100% conversion but a lot to make other changes easy) that can convert all VB.NET code to C# - they are cheap too.

Anyway, the issue in this case was that the code written before was crap as it would potentially have incorrect data set that will blow up at some point in run-time.

VB.net is sure ugly, but Pascal is worse

For conversion you can start writing NEW code in C# - you can have VS solutions that mix projects that have VB.net and C# code, this is really the best way to start moving towards C# - at least new stuff will be done in C# where as old stuff can be dealt with later.

[ASB]

For true ugliness you need Cobol.Net with object syntax.....

But IT'S SO SLOW........

The caret in editing windows keeps disappering. For no apparent reason the hourglass comes up for 10 seconds. Terrible.

I know my spec ain't too high, it's only a 1.5 ghzs mobile pentinum with 1 meg. Commited is only 600 mb and CPU is 6% when idle.