10 cosas que me gustan de C# respecto a VB

Antes de empezar a leer este post, un aviso: En ningún modo pretendo crear polémica o abrir el viejo debate otra vez, si no más bien enumerar algunas cosillas que hacen que *yo* me sienta más cómodo trabajando con C# que con VB, tanto a nivel de lenguaje como del propio editor. Lo remarco porque quiero que quede bien claro que es una opinión personal, ok? No se trata de comerle el coco a nadie…

Algunas de estas cosillas ya las he compartido con algunos de vosotros en algún evento de los grupos de usuarios, o simplemente delante de unas cervezas (aquí la conversación suele tornarse más pasional y tiende a alargarse un poco), jejeje…, y a decir verdad pocas veces nos ponemos de acuerdo ¿eh agüelo?. Parece ser que antes de empezar a hablar cada cual ya se ha posicionado y de aquí no nos movemos… lo cual es hasta cierto punto normal. Uno sabe con qué herramienta se encuentra más cómodo, aunque pueda usar ambas de forma indistinta.

De hecho he tirado más líneas de código con VB que con cualquier otro lenguaje, y eso que empecé en este mundillo con C y posteriormente con C++, para luego pasar a los lenguajes ‘más productivos’ como Delphi o finalmente VB en sus primeras versiones. No fue hasta 2002 y las primeras versiones de .NET que volví a usar la vieja sintaxis del punto y coma. De modo que VB en-todas-sus-variedades me es muy querido, y debo reconocerle sus ventajas… Sin embargo, codificar, al igual que leer o hablar, es algo que siempre haces mejor o te sientes más cómodo en uno de los lenguajes que dominas, y aquí reconozco que C# (como antes de conocerlo lo fue Java) es mi predilecto. Siempre que YO decido el lenguaje a utilizar en un nuevo proyecto, lo escojo, y en caso contrario intento convencer a la otra persona (ya sea compañero, cliente, etc.).

Os enumero a continuación una lista de cosas que me gustan de C#, o más bien que no me gustan cuando al cabo de un tiempo de trabajar con C#, me pongo a codificar con VB. No siguen ningún orden ni patrón y las voy a ir enumerando conforme se me vayan ocurriendo:

1) Escribo menos código && código más limpio:

En este punto, un desarrollador de VB acostumbra a decirme que esto no es cierto. Que si bien la sintaxis de VB es en alguno puntos ‘rocambolesca’ es para aclarar, y además el propio editor de código se encarga de escribirlo. Sin embargo tengo comprobado que con el editor de C# en la gran mayoría de las situaciones tecleo menos para decir lo mismo, y queda más claro (al menos para mí). Ojo! Es importante destacar que en ningún momento me mueve el afán de teclear menos, sino que el código resultante sea más legible. Comparemos los siguientes ejemplos:

Declarar una variable:

C#:

int x = 5;

VB:

Dim x As Int = 5

Bloques de código (ends por todas partes :-P).

C#:

if(Nombre == "Pepe" && Sueldo <= 500)

{

...

}

VB:

If Nombre = "Pepe" AndAlso Sueldo <= 500 Then

...

End If

Operador AddressOf

C#:

Thread t = new Thread(CountSheep);

VB:

Dim t As New Thread(AddressOf CountSheep)

Expresiones lambda:

C#:

Func<int, Func<int, int>> mult = (int x) => (int y) => x * y;

VB:

Dim mult As Func(Of Integer, Func(Of Integer, Integer)) = _    

Function(x As Integer) Function(y As Integer) x * y

Implementar una interfaz (no es preciso Implements):

C#:

interface ITest 

{ 

    string getValue();

}

class Test : ITest { 

    string getValue() 

    { 

        Random r = new Random(); 

        return r.Next().ToString(); 

    } 

}

VB:

Interface ITest    

    Function getValue() As String

End Interface 

Class Test    

    Implements ITest     

    Public Function getValue() As String Implements ITest.getValue

        Dim r As New Random

        Return r.Next().ToString()

    End Function

End Class

Podriamos seguir con Overridable, Overrides y unos cuantos más… Pero mejor vamos al siguiente punto que si no, no acabo el post hoy… 🙂

2) No más underscores!

Cuantas veces he tenido que escuchar “no tengo porque terminar cada línea de código con un punto y coma!”. Pues precisamente, el delimitador de línea es lo que permite que en los lenguajes derivados del viejo y bueno ‘C’ no tengamos que hacer algo tan antinatural como partir las líneas de código con underscores (_). Además suele pasar que es una de las cosas que olvido con mayor rapidez, y cada vez que escribo en VB una query con LINQ acabo por soltar un “AAAAARGH!!! OTRA VEZ!!!”.

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });

var mynums = from n in nums

             where n < 5

             orderby n

             select n;

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4}) 

Dim mynums = From n In nums _ 

    Where n < 5 _ 

    Order By n _ 

    Select n 

3) Matrices y Listas: [] en lugar de ():

Cuando estoy picando o leyendo código me gusta saber con exactitud si estoy llamando a una función, a una propiedad u obteniendo el valor de una matriz o colección. Precisamente por eso prefiero usar corchetes en lugar de paréntesis para acceder a los miembros de una matriz o lista. En el ejemplo siguiente en la llamada a nums(i) en VB, podría ser tanto un método como una matriz, como una propiedad que devuelve una matriz o lista:

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });

Console.WriteLine(nums[2].ToString());

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4}) 

Console.WriteLine(nums(2).ToString()) 

4) Parámetros de salida (out):

Tipos de parámetro de salida. Estos son muy parecidos a los parámetros por referencia (ref), pero no necesitan ser inicializados. Resultan particularmente útiles en algoritmos recursivos. Visual Basic no dispone de nada equivalente, aunque si permite el paso de valores por referencia.

C#:

static void Method(out int i)

{

    i = 44;

}

static void Main()

{

    int value;

    Method(out value);

}

5) Los códigos de escape y las cadenas verbatim:

Otra cosa que me molesta es que VB no reconoce los carácteres de escape contenidos en un string. Esto es particularmente útil cuando deseamos mostrar un retorno de línea ‘n’ o una tabulación ‘t’ dentro de una cadena. En Visual Basic hay que recorrer a la concatenación de Environment.NewLine o artimañas parecidas como concatenar directamente el carácter. Por ejemplo el código siguiente se muestra así:

MessageBox.Show("holanquental");

VB:

En este punto más de uno se preguntará ¿y que pasa si no quiero tratar estos caracteres de escape como especiales?, ¿o si quiero mostrar una ruta de acceso que contiene varios caracteres ‘’? Bien, para ello tenemos varias alternativas: Podemos anteponer un carácter ‘’ a todo símbolo que deseemos mostrar literalmente o podemos usar cadenas verbatim (también llamado ‘literal de cadena textual’):

MessageBox.Show("C:\Windows\system32\Calc.exe");

MessageBox.Show(@"holanquental");

Las cadenas verbatim van incluso un poco más allá y permiten incluso poder partir una cadena en varias líneas, lo que clarifica en mucho el código:

MessageBox.Show(@"SELECT O.OrderID, O.CustomerID, O.EmployeeID, 

                O.OrderDate, O.RequiredDate, O.ShippedDate, 

                O.ShipVia, O.Freight, O.ShipName, O.ShipAddress, 

                O.ShipCity, O.ShipRegion, O.ShipPostalCode, 

                O.ShipCountry, C.CompanyName, C.Address, 

                C.City, C.Region, C.PostalCode, C.Country

                FROM dbo.Customers AS C 

                INNER JOIN dbo.Orders AS O 

                ON C.CustomerID = O.CustomerID");

6) Propiedades autogeneradas:

Algo tan sencillo como crear una propiedad para una clase, lo es todavía más en C#, ya que permite el uso de propiedades autogeneradas. Esto hace que el compilador maneje internamente una variable privada a nivel de clase para almacenar el valor, quedando esta parte oculta al desarrollador. Esta característica estará disponible en la próxima versión de Visual Basic, pero de momento todavía tenemos que conformarnos con representarlo así:

C#:

class Foo

{

    public int id { get; set; }

    public string name { get; set; }

}

VB:

Class Foo 

    Private _id As Integer 

    Public Property id() As Integer 

        Get 

            Return _id 

        End Get 

        Set(ByVal value As Integer) 

            _id = value 

        End Set 

    End Property 

    Private _name As String 

    Public Property name() As String 

        Get 

            Return _name 

        End Get 

        Set(ByVal value As String) 

            _name = value 

        End Set 

    End Property 

End Class

7) Refactoring:

Hoy en día, al igual que el uso de pruebas unitarias, empieza a ser impensable no refactorizar el código para una mejor comprensión, que repercute en un mejor índice de mantenibilidad (o Maintainability index, vaya usted a saber cómo se traduce) del código. Bien, pues el menú ‘Refactor’ del editor de C# no aparece en VB. Y la única información acerca de refactorizar el código VB nos enlaza con un Add-In de terceros, la cual a decir verdad es una gran utilidad. Lo sé, porque he usado la versión PRO de este producto durante bastante tiempo. Pero el hecho es que Visual Studio no incorpora ninguna utilidad ‘de fábrica’ para refactorizar el código, lo que no deja de ser sorprendente…

8) Posibilidad de desactivar ‘Strict on’:

Al ser VB la evolución de un lenguaje no tan ‘estricto’ como C#, nos ofrece la posibilidad de desactivar la opción Strict On, y de este modo dejar que el compilador se encargue de realizar muchas conversiones implícitas. Pero lo más peligroso de todo es que la opción viene desactivada ‘de fábrica’ y en cambio no conozco ningún buen programador de VB (que los hay, y muchos) que no sea lo primero que active. Muchos errores en tiempo de ejecución podrían ser evitados si el propio compilador nos obligase a codificar correctamente, en lugar de actual de este modo más ‘relajado’:

VB (con Option Strict Off):

Dim s As String

s = DateTime.Today

VB (con Option Strict On):

Dim s As String

s = DateTime.Today.ToString()

Observar que con Option Strict activado, el compilador no permite asignar una fecha a una variable de tipo cadena (con razón!), de modo que para poder compilar debemos realizar una conversión explícita.

Recomiendo dar un vistazo a este artículo de coding horror:

http://www.codinghorror.com/blog/archives/000355.html

9) Microsoft.VisualBasic:

Son legión los programadores que provienen de versiones anteriores de .NET (6 o anteriores), de modo que para facilitarles el camino los proyectos de VB incorporan el espacio de nombres Microsoft.VisualBasic, el cual a su vez incorpora muchas de las funciones de estas versiones anteriores. El hecho de incorporarlas no es un error en sí, lo malo es que estas funciones tienen su equivalente en el modelo de objetos del framework, y si seguimos usando estas funciones ‘antiguas’ no aprenderemos las nuevas, y el día en que debamos trabajar con otro lenguaje del Framework (que no tiene porque ser C#, hay unos cuantos más :-P) nos encontraremos con que estamos usando funciones propias de VB y no conoceremos su equivalente.

Por ejemplo, en lugar de llamar a la función Len para averiguar el número de caracteres de una cadena, es mejor usar el método Lenght de la clase String, lo mismo para Trim(), y todavía es más flagrante con Mid(), que equivale al método SubString del objeto String:

Dim n As Integer = Len(DateTime.Now.ToLongDateString)    'NO

Dim n As Integer = DateTime.Now.ToLongDateString.Lenght  'SI

Hay muchas otras cosas que se quedan en el tintero, porque algunas de ellas son demasiado largas (como el manejo de eventos), y otras no son precisamente de uso diario, como la ejecución de código no seguro (unsafe). Pero estaremos de acuerdo en que la mayoría de las novedades aparecen primero para C# (inicializadores de colecciones, propiedades autogeneradas, soporte para expresiones lambda ‘de verdad’, etc.) e incluso los compiladores de C# del proyecto MoNo van siempre por delante de los de VB. Aunque este último punto reconozco que no es demasiado importante… o sí?

En fin, vaya chapa me ha salido! Pero por lo menos ahora tengo una lista de cosas para cuando me pregunten “¿porque te gusta más C# que VB?”.

Un saludo desde Andorra,