I've always thought, wouldn't it have been better for the C# IDE team to have it work like the VB IDE.
You've got to be kidding! The VB IDE is retarded!
If you want to handle an event in C# you do:
object.Event += [TAB][TAB]
and the IDE makes a delegate and an empty method with all the right parameters.. all you have to do is write the code.
What do we do in VB?
Write a sub, though we dont know the event signature:
Public Whatever Sub MyWhatever() Handles myObject.Disposed
We then do a full compile, and copy the error message:
Error 1 Method 'Public Sub Whatever()' cannot handle Event 'Public Event Disposed(sender As Object, e As System.EventArgs)' because they do not have the same signature. C:\Documents and Settings\cjard.THIMKPAD\Desktop\Software Dev\Local\Visual Studio 2005\Projects\WindowsApplication1\WindowsApplication1\Form1.vb 177 53 WindowsApplication1
and paste the error into the code, deleting the bits we dont want (keeping the bold bit above)
Now we finally have a sub that has the right signature for the event, we can addhandler it.
Woo. Er. Like I say -> retarded.
It would be great if I could get some consistency.. If I position to make a new sub and write "Overrides" i get a list of things to override, choose, press return, and there's my premade method signature! Why can't I write "Handles" and the class is scanned for event emitting objects, or at the least, write "Handles myObj." and get a list of events on myObj to handle..
Sticking with the IDE for a minute.. C# you want to make a private field a property? Cool. Right click it, choose the relevant option from the refactor menu..
Want a new property? type "prop" and press tab, fill in the green fields and youre done. VB, theres some Insert Snippets somewhere, but I cant find it let along navigate the 3 or 4 levels of menu obscuring what I want to do.
In C#, if you write a switch(select) and switch_on an enum for example, then the IDE creates a big block of all the options for you. VB, it inserts an example Select containing Case 1 (integer) and Case 2 and.. er.. that's your lot.
It's not adding up to a very helpful environment is it? Just about the best thing that it does is background compilation so that it can do unboxing/conversion based type checking so that the implied unboxing (yuck) can work at runtime. This is to counter the huge problem raised by option strict where you can write
Dim i as Integer = "1"
or
Dim o as Object = "hello {0}"
Dim s as String = String.Format(o, "world")
Yuck yuck yuck! The only people who will ever take issue with having a sensible amount of precision demanded of them, are those who are incapable of acting with that precision - people who dont know the difference between a string and an integer, or rely on the background compilaiton to unbox the string they just boxed into an object. Some things computers just should not do for us, because thye will get it wrong, or we will forget that they do it and performance will suffer
Another extremely annoying thing about C# (C++ and Java too) is those darn semicolons after every line except those rare occasions and the opening/closing brackets thing is the most confusing way to maintain blocks of code.
Proper indentation is the correct way to maintain blocks of code. In VB, every block of code is delimited by something different. IF delimited by END IF, FOR by NEXT..
C# is clean and consistent and uses fewer characters. Additionally, when we position the cursor near an opening or closing { } the other end of the block lights up so we can see how far it extends. Typing "break" in a for loop causes the statement that will break to light up; handy if you have a select/switch inside a loop
Using semicolons to denote when you have finished typing a line is a good thing, because in this day and age of OO, there are usually a lot of levels to dig through to get the method you want, which means the lines run to huge length and the VB guys have to put line continuations in all the time (if they want to adhere to a "no line of code longer than X characters" rule for readability.
Additionally as a multiline compare, see this:
string threeLines =
@"This is
a string split
over 3 lines";
Dim threeLines as String = _
"This is " & Environment.NewLine & _
"a string split " & Environment.NewLine & _
"over 3 lines";
Ya, VB makes things so much easier to read and quicker to type..
Note also that when compiled, these two are very different. The C# just puts a fixed string in. The VB contains a hidden string builder call:
Dim threeLines as String = New StringBuilder("This is ").Append(Environment.NewLine).Append("a string split ")
.Append(Environment.NewLine).Append("over 3 lines").ToString()
Nice! (note tha tI broke it into 2 lines manually so as not to distort the forum)
Here's another thing, while we're poking at legacy crap. Line continuations must be removed by the IDE before compilation. Why? Because this code works in c# and not in VB:
myMethod(
23, //person age in years
"Johnson", //person last name
"Joe" //person first name
);
mySub( _
23, _ 'person age in years
"Johnson", _ 'person last name
"Joe" _ 'person first name
)
Oops! The code becomes:
mySub( 23,
'person age in years "Johnson", 'person last name "Joe" 'person first name)
Which won't even compile.
Thanks to semi colons, simple stuff like proeprty sets and gets can be written on one line instead of the 10 or so that VB needs. VB is wordy and has a superfluous syntax, crazy default settings that promote poor quality programming (Option Strict/Explicit anyone) and doesnt offer its best programmers the options it should to really make use of their skills. Too many beards on the VB team I think..
I could go on, (and on) but hopefully I won't need to; (any kind of) basic is something of a language isolate these days, and most languages that are created from scratch or are evolving properly are arguably more consistent than VB is..
C# would be much more successful if they'd removed the annoying legacy crap.
C# is way more successful than VB, and without even getting into discussions over the absolute stupidities of resuing = for assignment/eqaulity or () for array indexes AND method calls, it ought to be clear to see that VB is carrying way more legacy crap from VB6. MS had the chance to clean up everyone's act, but they didnt - they provided libraries to allow MsgBox to continue into the future instead of obsoleting it immediately in order to have VB6 pasted code encouraged to upgrade. C# was the new language, built to a modern spec by ECMA, incorporating the best features from its forbears, java, c++ et al. As a new language it cannot possibly have any "legacy crap"?!
Note that noone is trying to paste old code into it and make it go, unlike all those people that think VB.NET is an upgrade to VB6..
) Getting a better habit of coding may save a lot of time and keypresses.
