Bander ALSHARFI

First, let me start off saying where my loyalty lies, I'm a C# guy.

I've recently been doing a great deal of work in VB.NET and I wanted to share with you what my thoughts are.

C# and VB.NET are identical in form and function. They can both be used to build the same identical systems with exactly the same code. There's no real difference - the beauty of the .NET Framework.

So what's this post about? Well it's about how I feel when writing code in the two different languages. What I write here is not about what's right and what's wrong, it's just opinion (personal opinion at that!).

To me, VB.NET feels like a very solid stable language, with well defined boundaries. Bold colours - you get what you see.

C# seems to be much more subtle, it feels less solid, the boundaries are there, but they're much softer, it's much harder to tell what you have in front of you with C#.

I don't get the same sense of completion with VB.NET as I do with C#, when I write code in VB.NET I know the code will do the job, but it just doesn't feel finished.

I wondered, is this because I just have not used the language enough which got me back to thinking about when I first started to learn .NET.

Way back in before .NET was released I was using VBScript and decided to try out the new .NET stuff, using the language I already knew - VB.NET (I mean it even had the same name!). I tried for about a month in my spare time to learn VB.NET, but I just could not get my head around it - all of a sudden I had all of these Object things to deal with and all the nasty casting going on - I really missed varients. I gave up on .NET and went back to VBScript - I knew it and knew it well.

A couple of months later I decided to give .NET a shot, but this time, I opted to give C# a go, see if I could lose the familiarity I had with the VB languages and teach myself .NET instead. This time round I found .NET much easier, the code samples were there, mostly in C#, the community was there, everyone was using C#, it just seemed easier for me to get my head around, all of a sudden these Object things gained a life of their own, I was able to write Classes and use design practices to ensure they were clean and tidy. I got .NET, and have never turned back to VBScript since that day.

So does the fact I learnt .NET with C# taint my feelings with the topic of VB.NET? I'm pretty sure it does. Is this a bad thing? Well for me at the moment, yes it is, I'm working with VB.NET quite heavily and I don't feel confidant in my code, a feeling I never really have with C#.

VB.NET is solid - I feel it does the job, but it just feels more chunky, rugged, designed for the world where it will be haphazardly put together. VB.NET to me is like Duplo (which for those who don't know is Lego for Toddlers - larger bricks, easier to use).

C# feels much more precise, it's smaller, easier to manipulate into a finer much more intricate design, it feels like it's better than VB.NET (which as I've already stated - it isn't they're equal in EVERY way).

So there you have it, VB.NET & C# side by Side do the same job, in the same way - they can both achieve wonderful things with morealess the same amount of code, okay, one language might have features the other doesn't, but essentially, they're pretty much identical.

The only real difference is the perception of developers who use either language. How someone overcomes this difference is beyond me, I'm looking to find a solution to the problem and to banish my VB.NET demons - I need to feel confidant that the vB.NET I write is a solid and as stable as my C# code - maybe I need to see a psychiatrist.

Reference: Phil Winstanley Blog

Microsoft added a new keyword to C# and VB for 2005 (CLR 2.0): partial

Don't use it.

partial is used to physically break up a class definition into multiple files. When the compiler sees the keyword partial it finds all the related partial files in order to compile the class. This makes it possible to split the code for a single class across multiple files. By and large, though, this is a bad idea. Let’s look at why that is.

If you find
yourself typing
"p-a-r-t-i-a-l"
Stop!

Reasons Given To Use the “partial” keyword

There are three main incentives I’ve heard for using partial, according to Microsoft and others:

1. If a class is really large, break it into multiple files so more than one person can work on it at a time.
2. If a class implements multiple interfaces, put the methods that implement each interface into a separate file.
3. When the IDE generates code, it puts the code into a separate file so you don't see it or accidentally modify it.

Let's examine each of these reasons in detail.

1. Avoid using “partial” to break large files into many smaller files—so multiple people can work on them. This is a bad practice.

Why?

No matter how you try to group code in various partial files, you will never see the big picture for the class anymore. It’ll become brittle, easily broken. By only viewing a portion of the class, you can too easily break some assumption or dependency in the rest of the class. For example, you won’t see all the internal fields. If a field needs updating, and it’s not referenced in the portion of the class you’re editing, you’ll never even realize that you are breaking the class. People will make incompatible changes and no one will know until Humpty Dumpty is put back together again. Are your unit tests good enough to catch this?

So what's the right solution for really large files?

If you’re thinking of using partial because your class file is large, then consider it a warning sign that it's time to break the class up—not by using partial but by using object oriented design. Break your monster class into multiple classes, grouped by responsibility. That way, you can hide details inside classes, and it will be much harder for developers who work on the new smaller classes to make incompatible changes with each other. As a bonus, breaking it up will also make your code easier to read, test, and maintain.

2. Avoid using “partial” to organize your class file. Some people suggest putting the implementations of each interface into their own files. This sounds reasonable at first, but it contains a pitfall—the class implements 2 or more interfaces, but it is still one class that has its own private data (and all the assumptions that go with that). If you only read code in one file and make changes, you may not realize the side effects you introduce on other methods that are in other partial files. This is a bad practice for the same reason that it was for reason #1, large class files.

 

3. “partial” is ok if the compiler puts it there. This is the only safe reason to use partial. When the compiler adds partial to your class, it does so to hide the code that it generates. While there are other solutions to handling generated code, this is the one that Microsoft chose, and it works fine. You can't ever modify the generated code (well, not easily) so it's just as well that it's hidden in a separate file. Note the key phrase here: the compiler adds partial—not you.

Recommendations

• If you find yourself typing "p-a-r-t-i-a-l" — stop! Don’t do it.
• If the class you’re working on is marked partial, make sure that the other partial bits are compiler-generated. If they’re not, you should consider putting the class files back together and re-factoring the large class into smaller classes.

One final Note: in VB, since the partial keyword is optional, you can really confuse someone reading the code because they may not even realize that other code exists for this class. If you work in VB, be aware that your entire class may not be in the file you’re looking at.

For another viewpoint, see these articles:

• This is a well written article describing partial classes: http://www.devx.com/dotnet/Article/22603
• Microsoft’s article on partial (and other things): http://msdn.microsoft.com/msdnmag/issues/06/00/C20/defaul...

source: http://geekswithblogs.net/dchestnutt/archive/2006/04/05/7...