Celebrity Deathmatch (VB.NET vs C#)
-
AspDotNetDev wrote:
VB.NET is Backward Compatible with VB6
And this is supposed to be a good thing? ;P Though I will give you props for actually using an ErrorHandler and not simply going with On Error Resume Next like my predecessor did.
And actually, it isn't. Migrating VB6 code to VB.NET can be a royal pain, and usually ends up as a rewrite (in C#).
-
I'll give an example reply as well... VB.NET is Backward Compatible with VB6
On Error GoTo ErrorHandler Throw New Exception("Error!") Return
ErrorHandler:
MessageBox.Show("Darn!")C# does not have this handy backward compatibility, so upgrading from VB6 is more difficult when going to C#.
He said post something that makes it better just kidding. Humble Programmer
-
True, but it can only be used with a boolean value. The others can work with non-boolean values.
-
Ever tried writing dynamic (X/HT)ML?
Dim header =
<%= publicationdate %>
That's a lot easier than anything in C#. Stringbuilders, XMLwriters, whatever... doesn't beat VB.NET's XML Literals.
Yeah, that is nice.
-
Huh? Did you reply to the right message? I don't know what you mean.
-
True, but it can only be used with a boolean value. The others can work with non-boolean values.
-
Does
Func<bool>
accept non-bool funcs? If not the other C# examples here only accept bool too. Or am I missing the point here?See the tip/trick I just posted. You don't have to use
Func<bool>
. You can use whatever return type you need. You can even useFunc<Object>
if you like. I'm not sure, but I think covariance or contravariance (I forget which is which) may allow you to still avoid having to wrap the functions in a new lambda. -
AspDotNetDev wrote:
Maybe "End Sub" makes the code easier to read to somebody not initiated with the language, but it doesn't make the code any easier to write
Which is a reasonable trade-off. You write code once and read it many times. Besides, with any decent editor, it is a non-issue.
AspDotNetDev wrote:
if (true)
{I see unnecessary and confusing symbols here. For instance in Go, it would be something like:
if true {
Or (even better) in ML:
if true then
#define then {
-
Yes, it can, but you want the process to complete each routine until it reaches a true condition, so your code has a bug in it (correct version): static void Main(string[] args) { bool s = !step1() && !step2() && !step3(); Console.Read(); } static bool step1() { Console.WriteLine("Step 1"); return false; } static bool step2() { Console.WriteLine("Step 2"); return true; } static bool step3() { Console.WriteLine("Step 3"); return false; }
-
Yes, it can, but you want the process to complete each routine until it reaches a true condition, so your code has a bug in it (correct version): static void Main(string[] args) { bool s = !step1() && !step2() && !step3(); Console.Read(); } static bool step1() { Console.WriteLine("Step 1"); return false; } static bool step2() { Console.WriteLine("Step 2"); return true; } static bool step3() { Console.WriteLine("Step 3"); return false; }
Nope, 'cechode' wrote: General Re: Celebrity Deathmatch (VB.NET vs C#) Pin member cechode 23hrs 30mins ago i'm not a vb guy anymore but when i was i LOVED exit on first failed step. ( instead of nested if's ) BTW, I would use
bool s = step1() || step2() || step3();
to execute until first true result. -
VB.NET supports by-ref extension methods. As of 4.0, C# does not.
Regards, Nish
Are you addicted to CP? If so, check this out: The Code Project Forum Analyzer : Find out how much of a life you don't have! My technology blog: voidnish.wordpress.com
Nishant Sivakumar wrote:
VB.NET supports by-ref extension methods. As of 4.0, C# does not.
WHAT!!! I don't have 4.0 version. This continues to work in 3.5: void step1(ref int x)... Are you saying all legacy C# code that uses that convention is now broken in 4.0, or did I misunderstand what you said? One thing I do have to do in 3.5 is initialize the int variable's value being passed. (Unless I use out instead of ref.) Something is rather goofy in VB.NET, I can pass a referential object as a by val field if I want. (It, of course, remains by ref.)
-
There hasn't been a good "why language X sucks and language Y is better" thread in a good while, so I thought I'd start one. Unlike most, however, this one has rules. I will post a reason C# is better than VB.NET and somebody reply with a reason VB.NET is better than C#. I (or somebody else) will then reply to that message stating another reason C# is better. And so on. Also, you must show code examples (when appropriate). I'll start. C# Is Less Verbose
Public Sub Something()
' VB.NET...
End Subpublic void Something()
{
// C#...
}You're turn (post why VB.NET is better than C#). :)
in C#:
i_can_do_this(); and_this(); //in the same line
Because of the delimeter, sometimes it makes sense not to waste one line and make the code more readable, especially when assigning multiple variables in the same context. -- Turns out you can do it in VB with ":" check the reply bellow.
modified on Tuesday, March 29, 2011 7:11 PM
-
Perhaps I should have said "C# Is More Concise". :rolleyes: But kudos to you for bringing up the counter point that VB.NET is more expressive. I think, however, that it's expressive in areas which do not require expressiveness. Maybe "End Sub" makes the code easier to read to somebody not initiated with the language, but it doesn't make the code any easier to write (you would have to know the "End Sub" in advance, so it's not expressing anything until you write it yourself). Of course, intellisense adds "End Whatever" for you, which brings me to my counter point: If-Statements Are Easier To Type in C# Supposing you have a code block and you want to surround it with an if-statement. In VB.NET, you must type "End If" in full:
If True Then
' Code Block.If you press ENTER after "Then", the "End If" will be added in the wrong place. Instead, you can go to the bottom of the code block and type "End If". In C#:
if (true)
{
// Code Block.All you have to type is "}" and the code auto-indents nicely. Along those same lines, C# waits until you type the closing brace... VB.NET is a little eager and indents the code before you need it to.
Now you are getting into intellisense (mis-)behavior. The difference in code behavior is basically C#: unless I tell you different, the next line is part of the same command VB: unless I tell you different, the next line is NOT part of the same command. "If" is one of those awkward step children that don't follow that rule very well. I agree with you, there is generally more typing in VB than in C#, whether or not you use VS to build your code. If I remember VB.NET correctly, you type If... and carriage return, it doesn't place the End If incorrectly, just awkwardly in relation to your cursor position and the commands you want to enter into the block.
-
There hasn't been a good "why language X sucks and language Y is better" thread in a good while, so I thought I'd start one. Unlike most, however, this one has rules. I will post a reason C# is better than VB.NET and somebody reply with a reason VB.NET is better than C#. I (or somebody else) will then reply to that message stating another reason C# is better. And so on. Also, you must show code examples (when appropriate). I'll start. C# Is Less Verbose
Public Sub Something()
' VB.NET...
End Subpublic void Something()
{
// C#...
}You're turn (post why VB.NET is better than C#). :)
VB has Explicit Event handlers VB:
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
End Sub
C#:
private void Form1_Load(object sender, EventArgs e)
{ }
This comes in real handy when you need the same event to handle multiple controls on a form.
Mike
-
VB is better because I use it more often, and have more experience with it than C#. Do I get points for honesty?
Michael K Gray wrote:
Do I get points for honesty?
I don't think so, at least in the rules set out. The rules kind of limit the playing field to people who have a fairly good knowledge of both. The fact that you can turn out code more quickly (and I assume accurately) in VB is offset by those who can say the same about C#. I wouldn't worry about it, this battle is all tongue-in-cheek(TIC). Your point just reinforces that everything said here has to be TIC.
-
in C#:
i_can_do_this(); and_this(); //in the same line
Because of the delimeter, sometimes it makes sense not to waste one line and make the code more readable, especially when assigning multiple variables in the same context. -- Turns out you can do it in VB with ":" check the reply bellow.
modified on Tuesday, March 29, 2011 7:11 PM
-
VB has a ":" colon to seperate multiple statements in the same line. statement1 : statement2
Mike
-
in C#:
i_can_do_this(); and_this(); //in the same line
Because of the delimeter, sometimes it makes sense not to waste one line and make the code more readable, especially when assigning multiple variables in the same context. -- Turns out you can do it in VB with ":" check the reply bellow.
modified on Tuesday, March 29, 2011 7:11 PM
-
Nishant Sivakumar wrote:
VB.NET supports by-ref extension methods. As of 4.0, C# does not.
WHAT!!! I don't have 4.0 version. This continues to work in 3.5: void step1(ref int x)... Are you saying all legacy C# code that uses that convention is now broken in 4.0, or did I misunderstand what you said? One thing I do have to do in 3.5 is initialize the int variable's value being passed. (Unless I use out instead of ref.) Something is rather goofy in VB.NET, I can pass a referential object as a by val field if I want. (It, of course, remains by ref.)
KP Lee wrote:
WHAT!!!
I don't have 4.0 version. This continues to work in 3.5: void step1(ref int x)...
Are you saying all legacy C# code that uses that convention is now broken in 4.0, or did I misunderstand what you said?You did misunderstand what I said :-) I did not mean the method arguments, I meant the source object. In VB the source object itself can be passed by reference.
Regards, Nish
Are you addicted to CP? If so, check this out: The Code Project Forum Analyzer : Find out how much of a life you don't have! My technology blog: voidnish.wordpress.com
-
VB has Explicit Event handlers VB:
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
End Sub
C#:
private void Form1_Load(object sender, EventArgs e)
{ }
This comes in real handy when you need the same event to handle multiple controls on a form.
Mike
obermd wrote:
VB has Explicit Event handlers
So??? You can handle multiple controls with the same function in C#. I have a 7X7 arrary of text boxes where the name is "n" plus the two index values converted to strings and appended. I happened to only need 9 events to go to the same function. I think you misstated this:
obermd wrote:
you need the same event to handle multiple controls
I think you meant "you need the same function to handle the same event in multiple controls" Personally I really like C# a lot better in this respect. This could just be because of my inexperience with VB, but I simply could not bind the events directly to the object in the array of text boxes, I had to create nine named fields, set them equal to the explicitly indexed box in the array, and manually list out all nine named fields with their event type in the function declaration. I shudder to think what the code would look like with all 49 events pointing to the same function. In C# each event delegates to the same function in a separate command, it has no direct tie to the function declaration. This is great, I just add the events directly from a do loop. I have no idea how to tie events to a function in a do loop in VB. (Just imagine the swearing I did when it wouldn't work, the frantic scrambling trying to find the documention of how multiple events to 1 function work in VB, then finding out specifically indexed controls in an array can't be tied to a function. ARRRGGGG.) OK, I had an advantage with C#. I took classes, that required books, and that mainly trained me to do some of this stuff.