I've been in workplaces where, at the start of a project, the "Should we use VB.Net or C#" question has been raised.
Granted, it's probably less common to have to make that decision now than it was in the early days of .Net, particularly given the trend towards language convergence, but it can still be a heated debate.
So, between VB.Net and C#, Which language do you prefer and why?
I prefer C# over VB.NET because
(from stackoverflow)
I hate VB.NET. The days I still spend using it are the days I regret. That said, my tastes are a part of my situation and experience, and don't necessarily have any relevance to what you're doing...
I think it is important, when comparing continually-evolving languages like C# and VB.NET, to look back at their history and see how they arrived at their current state:
The original advantages of BASIC on microcomputers included size and simplicity (small, easy-to-parse syntax made for small, reasonably fast interpreters and left room in memory for the actual program and data), an interactive environment that enabled experimentation, and a syntax that eschewed terse symbols and structures for a reasonably clear, English-like syntax. It was poorly-suited for large, structured programs however, and tended to encourage spaghetti code. Still, its availability and simplicity made it an excellent choice for an introduction to programming.
QuickBasic updated the syntax to allow for large more structured programs, and added compilation for faster execution.
VisualBasic provided a powerful, easy-to-use form builder to enable rapid construction of GUI applications, while adopting the QB syntax for use in scripting these UIs. It worked best when used to create UIs for low-level logic provided as pre-built components (usually written in some other language). Over time, the syntax became increasingly large and inconsistent as new features were tacked on. The focus on drawing up a UI first and then filling in bits of script worked well for small, UI-centered apps, but tended to encourage copy-paste programming and a variation on spaghetti code while discouraging re-use, complex data structures, and separation of concerns. In the minds of many, "VB code" became synonymous with "big ball of mud"; "VB programmer" with "inexperienced hack".
VB.NET is a VB-like language on the .NET platform, an attempt (not entirely successful) to clean up and modernize the overgrown VB syntax. It was not perfectly compatible with existing VB code, and made no effort to provide compatibility with VB forms (arguably the most important part of VB) whatsoever. This left many VB product owners with the unpleasant choice of effectively re-writing their applications in VB.NET (dealing with subtle incompatibilities in every routine that wasn't carefully examined) or actually re-writing their applications in C# (dealing with an unfamiliar syntax in addition to the new runtime library and forms designer). Most VB.NET users were VB users who stuck with it for the syntax alone, many using it as a crutch while learning C#. As a result, it immediately took on a reputation as a haven for programmers who had become stuck in their ways, unwilling or unable to expand or improve their skills.
At this point in time, VB.NET continues to evolve, slowly shedding baggage while picking up new and interesting syntax (LINQ, XML literals). Still, it retains almost none of the original advantages of BASIC: it is a large, complex language with a fairly steep learning curve and limited opportunity for interactive experimentation.
I'm familiar with both, but did a lot of my early programming work in VB4, VB5, and VB6. Now that both languages in .NET have gone through a few iterations and converged quite a bit in their capabilities I think the debate is downright silly, much akin to "what's your favorite color."
Personally, I like both of them for different reasons.
VB.NET
A lot of people talk about how the C# syntax is more intuitive, but that is very subjective and based heavily on what you started out knowing. I would argue that if you were completely objective VB.NET syntax is probably more intuitive if you don't assume prior knowledge in another language. For example, given the same program in C# and VB.NET which do you think would be more decipherable to someone who has no knowledge of programming. Seems pretty clear to me.
The other thing that is nice about this syntax, is that is is much more explicit about closing structures (END IF, END WHILE, NEXT X) compared to the bracketing model. It makes the code a bit more readable and often allows the compiler to be more precise in what line number exactly is causing compile errors. If you've ever gone on a missing bracket/semi-colon hunt because of a compiler error 50 lines away from the problem you know what I mean.
Also, in the VB.NET win column in my opinion is lack of ==/= as comparison/assignment operators. The rare benefits of having a distinct operator for each is never going to offset all the (sometimes) hard to discover foibles that it helps create.
Finally, I hate case sensitivity in programing languages. One of the complaints about VB is that it has so much baggage, but C# carried forward the albatross of C's case sensitivity. I have never been in a situation where I wanted two identifiers in the same scope to differ only by case. It just makes for busy work and slows me down. VB.NET gets some points over C# in this regard to me.
C#
Programmers love to be concise, which is why I think they generally favor this syntax. It just has a certain aesthetic appeal. However, from a completely practical perspective I like it because it is so similar to languages like Java, JavaScript, and C++.
Since I do a lot of web development that requires both server and client side programming, I find it easier to mentally switch between C# and JavaScript as I am frequently required to do.
Also I like the fact that, for the most part, that if I ever had to transition to doing Java or C++ programming, I would have a bit of a head start if I were using C# most of the time.
name and a public property with the name Name and then assign it through Name = name;. As long as you keep a coding standard, else I agree, then it can cause confusion.
Commented
Oct 18, 2011 at 11:52
I prefer the bracket syntax of C-style languages to the more "verbose" syntax of BASIC-style languages.
My introduction to programming was with Turbo Pascal. (The bit of BASIC programming I did on the Commodore 64, as a child, doesn't really count.) After learning Java I never looked back and have preferred C-style syntax.
if something then code endif
They are functionally the same, there is nothing you can do in one you can't do in the other, and for the future Microsoft have pledged that the language teams will develop both evenly so this is equivalence unlikely to change.
The differences now are purely cultural and personal. This article is interesting reading on the differences between the cultures of programmers using C# and VB.net
[Note: Although I'm a C# dev myself, the linked article's conclusion does not necessarily reflect my personal opinion, it's just an interesting alternative approach in the debate]
I came to .NET from C and C++ (with a bit of Java, Ada and Pascal thrown in) so C# was the natural progression for me.
If a job came along that required VB.NET I certainly wouldn't turn it down.
I've done a lot of work with VB.NET, but I understand enough C# to get the gist of what is happening in the code. My current preference is VB.NET because I am most familiar with it (obviously), but I don't really have a preference between verbose BASIC syntax and C-style syntax, both are very readable and understandable to me.
Most of my coworker's programming background is COBOL and VB6, so VB.NET was the more comfortable .NET language choice for us as a team. There wasn't a solid reason for us that made learning C# a requirement since they are functionally the same.
That said, learning C# is most definitely on my list of things to do.
I prefer C#.
I started as VB.NET programmer but with passing of time it became obvious that quite a lot of new features are coming first to C# and then later to VB.NET (e.g. automatic property). And community surrounding C# is much more lively than VB.NETs one.
Additionally, if you intend to learn Java or similar language, C# is better starting point - syntax is almost same in all C-derived languages. Although this would not be tipping point for me since syntax is something you can learn quickly anyhow.
Object.ReferenceEquals, event handling that's almost done right, and a smoother IDE experience. VB.net makes it possible, albeit slightly awkward, to have field initializers use constructor parameters or safely create IDisposable objects without having to use ThreadStatic variables; C# does not.
In addition to the other answers posted here, I would choose C# over VB because C# programmers get paid more. More experience with C# = more $$ :)
I know both languages are almost the same and its really easy to switch between the two, but I think when management looks at a bunch of curly braces and semi-colons they accept the fact we are doing something they cannot do, where with VB.Net they might look at it and go "oh that must not be that hard to do if I can understand it".
C# because I can switch between it and Java with minimal effort
VB.NET is entirely different syntax. C#, being similar to Java and other languages gives me a better position to quickly adapt to new things. Since the output of C# and VB.NET are virtually interchangeable, it makes sense to go with C#. Plus, if your company's code is in C#, you're more likely to be able to train a Java developer how to code C# than a Java developer VB. There are only subtle advantages, but subtle is still an advantage.
Putting my personal preferences aside. As someone who's been recruiting (and trying to be recruited) lately, when we had this debate in the office the general consensus was that we should look to move to C# from VB.
Why? Because C# was more prevalent in the market (around us anyway), allowing us to recruit more easily, and be recruited more easily.
It looks like it's gone full circle; people learn C# because recruiters want it, because there are more candidates.
Being a somewhat older dev (is 59 "somewhat" older?), I learned BASIC first on a Commodore VIC-20, taught myself Turbo Pascal (v1!), went on to learn COBOL at college, and spent 14 years developing on IBM mainframes, with brief diversions writing a medium sized apps in Revelation BASIC (a variant of PICK BASIC) and a few utilities in Modula-2, before side-stepping over to VB5 and VB6. And then came .NET.
Because of my Basic background, I thought I should start out with VB.NET, only to find that I kept trying to do things the "old" way and it was driving me nuts (okay, more nuts). Being that I had done some work in C, I thought I would give C# a whirl to see how that went. And OMG, that was like emerging from a dark tunnel into clear daylight! Totally unexpected. And I used to make disparaging noises about C being a "write-only" language -- "so hard to understand that a C programmer couldn't figure out what his own code did 6 months after he wrote it", an observation made by semi-famous novelist that I thought sounded cute at the time.
So, by virtue of being a bit unfamiliar with C, C# was paradoxically easier for me to learn .NET programming in than the far more should-be-familiar Basic paradigm. I still like VB6, but have come to love C#. The best programming language on the planet.
I develop in Visual Basic .Net since 2001 and I love it and I hate it!!!
The order of presentation of these points is just based on the order in which he came to my mind...
In vb.net with visual studio, there is a visual line break between each method, property. For many people, it's not a good reason to prefer vb.net over c# but I don't understand why the c# team at Microsoft don't have implemented it. There is a add-in that draw this line in c# but thanx again Microsoft to have a c# team and visual basic team that don't talk to each other.
In vb.net, when you create a winform, you have two combobox in visual studio at the top of the editor and you can auto-generate event automatically when selecting an event on the right combobox. When you attach dozens of events each day, it can be very cumbersome to don't have this feature. With c#, you have a small button at the top of the property grid that can generate event but it's not fast as in vb.net. More, if you attach event of control in c# and delete the control on the form, the delegate created on the auto-generated code to handle event have to be deleted manually. Thank you again Microsoft.
In vb.net, when you try to modify a method that contain a linq query without modify the query itself, no problem but in c#, all the method code is locked. If you have a lots of linq queries or lambda expression, the edit and continue feature will rapidly be a good old thing. Ok, a little bit of exaggeration... but :)
In vb.net, when you create a method name and tap enter, the 'end sub' will be automatically created. In c#, do it yourself. Ok, if you have resharper or devexpress installed, it will be better but why all these little but greats features were not be implemented in c#.
In vb.net, when you have errors on your code, the errors are automatically displayed and when you correct it, these errors are removed of the stack in real time. In c#, you have to build your project to realize that you have successfully corrected or not the specified errors. Why c# team don't have put an option to verify in real time error like in vb.net. With big solution, no real time verification of error can be a very nice optimization of performance but I love to see a stack of error disapear while I correct it.
Like other person have mentionned, I think it's more easy to read vb.net condition if..end if, select case... end select but with devexpress painting bracket, forget what I said.
With vb.net, there are many many bugs in visual studio. Just to mention one in visual studio 2010, the intellisens don't filter correctly enumeration if you have the mode "common" activated instead of "all".
With vb.net, you are perceived as a dummy guy because statically, more bad programmers use vb.net instead of c# because c# is harder to learn and promote better programming practice.
Like other said, c# programmer have better chance to have a good job with more money.
In the head of customer, vb.net = guy who program in his basement with a bol of spaghetti of code. c# = wow, you are very intelligent. The fact is that it's not because you program in c#, that you make a good program but statically, yes.
With all these points, I chose to convert all my vb code in c#. I program with all the best practices of object oriented, design pattern, clean code with standards and strict syntaxe and I can program like that for 50 years but from the eyes of community, I'm not a good programmer. I will convert my code in c# with no other best practices and I will be another person; a great guy who you must respect..... :( what a joke...!!! but it's the reality.
Here's a way of looking at it: Between SO and CodePlex, which language is more popular? C# or VB.Net?
Sometimes, following the herd is a good thing because it's the herd that's going to be able to help you when you need it. By default, C# will be faster than Vb.Net. I believe using Option Strict might equalize it though. The last time I compared IL between the two, VB.Net's type safety ended up adding about 15% more to the IL. This translates into extra overhead. AND... given languages that do basically the same thing, I'll take the faster one. My convenience should not override my user's experience in general.
I like to say that the only reason BASIC is still popular is that it was Microsoft's first product, and they've be shoving it down our throats for the past 35 years. It should have died a long time ago.
With that said, I've worked on two sizable .NET projects and both were done with VB.Net - though there was a bit of C# because either the translation was a bitch, or the construct didn't exist in VB.Net. The only advantage I see with VB.Net is that the Visual Studio editor is much more friendly to it (in my experience anyway) than it is with C# - Intellisense seems better, and so does autoformatting (note that since I have not used C# as much, I may just be missing something in the configuration of the IDE...)
A major disadvantage in VB.Net is that they brought in a lot of VB6-era crap way back in .NET 1.x to ease the conversion of VB6 code. That stuff is still in there, and VB6 coders are coding new code using those... "extensions" rather than using the more neutral .NET classes/methods/whatever. I don't know how many times I asked my boss why he still used that crap. "But... It works..." Right. Hey, I like to bitch.
While looking for help on the web, I found the vast majority of solutions were in C# - check out the MSDN forums, various blogs, etc... Books have a tendency to focus on C#, and if there is a VB version, it usually comes in months later (e.g. Pro LINQ.... from Apress.)
Many languages share the C ancestry, which makes switching between C, C++, C#, Java, PHP and a few others much easier. PHP is a bit of a stretch here, but it does have a lot of C-like constructs. VB? Well, it's pretty much its own little thing and that's that.
A project leader in my organization recently told me that more and more new projects are being developed using C# instead of VB - FINALLY. When .NET was introduced in our organization, they more-or-less-officially went with VB.Net because of all the VB6 coding that was already going on. The powers that be later admitted to me that that wasn't their best move.
As somebody else above pointed out, I wouldn't say no to a VB.Net project, but I'm still hoping that it will be slowly eradicated from newer development at my place of work.
Well, today there's little to none real reason to use VB.net. In the beginning it was just a way to give give VB programmers a familiar syntax, but was essentially a BASIC-like remapping of C#. So its only real advantage is a more familiar syntax, and its BASIC syntax is also its real only limit.
Over the time the two languages evolved alongside, the only significant difference is the my pseudo namespace.
I would advice every .net programmer that is not familiar to C# to learn it, as the community is fairly larger and the C-like syntax is common to most of the more used languages.
VB the language is easier to read for newbies, they tend to write their first, second and third application in it and we all know what our first applications are coded like - terribly.
Programmers from C++, Java and etc have moved to C# whilst VB.NET developers come from VBA, VB and BASIC background, essential non-traditional programmers.
There seem to be more C# code samples online than VB.NET samples. Not like its all that hard to convert one to the other, but why bother if you don't have to.
I prefer VB .Net over C#,
C#. It's just because I have done C and Java, so I feel that C# is more readable to me. C# is for me, as VB.NET is for former VB programmers.
