[ENG] Recommendations to develop with Visual Basic .NET (part I)

Today I want to share with you something that has always been much debate.

For years the developers of C# and VB have debated about which language is better there, to clarify some things that in my opinion, Visual Basic continues dragging things from versions as Visual Basic 6, that was very popular in the past, and that even though it is practically an obsolete language, even in the current versions (I use Visual Studio 2013) continue supporting features of the past.

With this, I don’t mean that Visual Basic is bad, the bad thing is that it still supports things that at the end and after the bad practices constitute.

Let’s take a look at some:

Option Strict

Unfortunately until today, this option is disabled by default, this option if it is enabled, prevents that when we declare a variable of a type for example String, we can not assign a value other than the one stated.

For example, when it is disabled can do things like this:

And if in case it is enabled:

It would show us these assignments as compilation errors, which we must rectify before generating our Assembly.

The good news is that we can enable this feature from 3 different areas:

By code file:

Simply by typing in the first line of code

By project:

Double click on the My Project from the project folder, tab to Compile and then choose the option:

Forever in new projects:

In the Menu Tools – > Options – > Projects & Solutions – > VB Defaults

Obviously this option will only allow for new projects, it is not retroactive. As you can see C# don’t even contemplate this option since this is the default.

Case Sensitive

Another feature of Visual Basic is that we declare a variable in all caps for example, and then referenced in lowercase, and will give us an identical result, no any problem or any compilation error.

But (there always is one) is a bad practice by not declaring the variables correctly, since if we got used to do this, in the long run, we will not have a standard, and that we can lead to hours and hours to give maintenance to a system even more when the project is huge.

Again, C# is very strict on this issue (like Java) and requires that the variables are always sensitive to capital letters or lower case letters.

Project level imports

This is a feature that I loved very much at the beginning when developing with Visual Basic, as if it required reference to a class that is in another namespace, and needed it in many kinds of my project(s) simply was leading me to the folder of My Project from the project then References, and in the bottom box marked spaces of names that would have to be referenced in all classes of the project in question.

This represents a «saving» writing code in all classes, but (another one), when you have so many kinds, in huge projects, is a mess knowing to which namespace belong, unless you go by pressing the F12 Key (Go to Definition) in each class that requires knowing which namespace or assembly from.

Again, C# forces you to that declares the Using (Imports in VB) in each class that you encode.

Classes vs. Modules

This is a controversial issue, the modules, they are a legacy of the old Visual Basic 6, since on this type of special classes, we can declare variables, types, constants, enumerations, events and delegates publicly without creating an instance of the same, this can be very convenient if we centralize in a single place.

But (Yes, here I go again), we can access such members, without the need to explicitly call the module containing it, and here comes the terrible mistake, that if we proceed with this throughout the construction of our project, we can be confused with ease which module from a member if it is that we handle more than one.

The ideal is to always get used to using the name of the module, then a point and then the Member to which you want to access.

C# does not allow to create modules, classes are in place, but we can define static classes if we need to use one in particular that only declare members that we need to have public access from the entire project and do not need to create an instance of that object.

This is only the first part of my recommendations from Visual Basic. NET, stay tuned to the second part.

I hope they serve.