Prefiro C# do que VB.Net - Parte 2

Introdução

Continuando as razões de eu preferir a sintaxe do C#. Na primeira parte abordei dois pontos da linguagem que apesar de ser maneiras de auxiliar quem veio do VB6 poderia confundir na parte de orientação a objetos. Mas elas eram apenas duas exceções da linguagem.

Vamos continuar então.

Membros Públicos dos Módulos

Você sabe o que é um módulo?

Um módulo é uma classe onde tudo nela é shared(static em C#) por padrão.

Então o modulo seria equivalente a isso no C#:

public static class MinhaClasse 
{
}

Então qual o problema do módulo ou melhor dizendo classe shared no VB.Net?

Seus métodos, atributos públicos são vistos em todos os lugares sem
precisar mencionar o modulo(classe).

Por exemplo, criei um "Module1" com uma property(Id), por ser shared eu nem devo instanciar um objeto para acessar a variável, basta colocar o nome da classe ou modulo assim:

 Module1.Id = 1

Mas no VB.Net você consegue setar a property sem nem ao menos colocar o nome da classe na frente, ou seja, você está numa classe totalmente diferente e pode utilizar os membros de um modulo como se você estivesse dentro do modulo:

Id = 1  

Você pode estar se perguntando, o que tem de errado nisso?
Vou dar um exemplo: Um programador cria um “MdlGlobal”, modulo com propósito de conter variáveis e métodos globais, e coloca lá variáveis e métodos que ele quer que seja acessados por toda aplicação, mas para não confundir com membros de outras classes acabaram colocando prefixos nos nomes para dizer que é Global, exemplo: GlobalUsuarioID, GlobalVariavelX (e etc)

Isso acaba deixando tudo mais confuso, se fosse obrigatório o nome do modulo não precisaria de prefixos: MdlGlobal.UsuarioID, MdGlobal.VariavelX

Não ficou mais fácil? Alem de deixar os nomes menos carregados você sabe rapidamente da onde está vindo o método ou atributo.

Da para deixar de usar módulos criando uma classe e colocando os membros como shared, é uma alternativa.
É fato que quando usamos shared deixamos o código menos orientado a objetos, mas nem mencionar a classe daí já é demais.

Método/Método()

No VB.Net na passagem de parâmetros de métodos é obrigatório colocar os parênteses a não ser quando não há parâmetros.

Dim letras As Object = "a b c d e f g"
Dim array As String() = letras.ToString.Split

O exemplo acima talvez não esteja confuso, porque os métodos ToString e Split tem nomes intuitivos, da para entender que está executando dois métodos. Mas quando o programador coloca um nome nada a ver para um método? Um nome que deveria ser de um atributo? Bem, no Visual Studio basta passar o mouse em cima para descobrir, mas não deixa de ser confuso as vezes.

Mas isso pode ficar mais confuso combinado com as genérics que é o próximo tópico.

Generics com Parênteses

As generics são muito utilizadas, com ela tem um ganho muito bom em performance e em segurança.

Vamos declarar então uma lista de usuários.

Dim usuarios As List(Of Usuario)

Eu declarei usuarios como List(Of T), o T é a genéric que vai ser o meu tipo Usuario.
Ok, eu não instanciei ainda a minha lista.

usuarios = New List(Of Usuario)

Pronto, instanciei uma lista, nesse momento um método é executado, que é o construtor da classe. Por não ser obrigatório o uso de parênteses pode dar a impressão de que '(Of T)' que é a generic é o construtor ou que o construtor nem existe.

Dim usuarios As New List(Of Usuario)(100)

Veja agora, você não acha que isso é bizarro? Estou passando um parâmetro para o construtor da lista e ficou com quatro parênteses na minha declaração.
No C# ficaria assim:

List<Usuario> usuarios = new List<Usuario>(100);

No C# as generics ficaram menos confusas ou ao menos não tem como confundir com o construtor da classe.

Índices com Parênteses

Os indexadores no VB.Net também usa parênteses para acessar os índices de arrays e coleções em geral.

Exemplo:

x = numeros(1)

Estou atribuindo o valor da posição 1 para a variável ‘x’.
Nenhuma confusão até agora, pois o meu array está com um nome que sugere que é um array ou uma lista e ainda está em camelCasing que é uma boa pratica.

Digamos então que o programador não segue boas práticas:

x = SomaNumeros(1)

O que é SomaNumeros? O programador colocou um nome ambíguo, que para ele deve significar muita coisa e fazer todo o sentido do mundo.
Será que é uma lista ou array com resultados de uma soma ou é um método? Descobriremos somente se olharmos a definição, e isso não é bom.

A sintaxe do C# utiliza colchetes para indexar, então não tem erro:

x = SomaNumeros[1];

Declarando Arrays

Quantas posições estou alocando com a declaração abaixo?

Dim numeros(10) As Integer

A resposta é onze!
No VB.Net ele aloca de zero até o número especificado, que no caso é dez.

No C# alocaria de zero a nove dando sentido ao número explicito da declaração. 

Isso induz o programador deixar de usar o endereço zero desperdiçando memória.

Mas você quer ver como isso pode ficar estranho?

Dim numeros(0) As Integer

Declarei acima um array de apenas uma posição com o número zero.

Chegando ao Fim da Parte 2

Eu abordei nessa segunda parte pontos da sintaxe do VB.Net.
Quando escrevemos um código limpo, com bons nomes nas variáveis e bem documentado não há confusão alguma independente da linguagem.
Então é bom nos disciplinar para fazer um código que facilite a manutenção.

Há mais ponto que me incomoda na linguagem, mas ficará para a terceira parte.

Até Mais,
Tiago Esmeraldino