O VB realmente não diferencia maiúsculas de minúsculas?

Não estou tentando iniciar um argumento aqui, mas por qualquer motivo, geralmente é afirmado que o Visual Basic não diferencia maiúsculas de minúsculas e as linguagens C não (e de alguma forma isso é uma coisa boa).

Mas aqui está minha pergunta: onde exatamente o Visual Basic não diferencia maiúsculas de minúsculas? Quando digito ...

Dim ss As String
Dim SS As String

... no IDE do Visual Studio 2008 ou do Visual Studio 2010 , o segundo tem um aviso de " A variável local SSjá está declarada no bloco atual ". No VBA VBE, ele não gera um erro imediatamente, mas apenas corrige automaticamente o caso.

Estou faltando algo aqui com este argumento de que o Visual Basic não diferencia maiúsculas de minúsculas? (Além disso, se você souber ou quiser responder, por que isso seria ruim?)

Por que estou fazendo essa pergunta?

Eu uso o Visual Basic em muitos de seus dialetos há anos, às vezes como hobby, às vezes para pequenos programas relacionados a negócios em um grupo de trabalho. Nos últimos seis meses, tenho trabalhado em um grande projeto, muito maior do que eu previa. Grande parte do código-fonte de exemplo existente em C #. Eu não tenho nenhum desejo ardente de aprender C #, mas se há coisas que estou perdendo que o C # oferece que o Visual Basic não oferece (o oposto seria o VB.NET oferecer literais XML ), então eu gostaria para saber mais sobre esse recurso. Portanto, nesse caso, é comum argumentar que as linguagens C diferenciam maiúsculas de minúsculas e isso é bom e o Visual Basic não diferencia maiúsculas de minúsculas e isso é ruim. Eu gostaria de saber...

1. Qual é exatamente a diferença entre maiúsculas e minúsculas do Visual Basic, pois todos os exemplos no editor de código se diferenciam entre maiúsculas e minúsculas (o que significa que o caso é corrigido), quer eu queira ou não.
2. Isso é convincente o suficiente para eu considerar a possibilidade de mudar para C # se o caso do VB.NET estiver de alguma forma limitando o que eu poderia fazer com o código?

A diferença entre VBA e VB.NET é apenas porque o VB.NET é compilado continuamente em segundo plano. Você receberá um erro ao compilar o VBA.

Como Jonathan diz , ao programar, você pode considerar o VB.NET sem distinção entre maiúsculas e minúsculas, além de comparações de strings, XML e algumas outras situações ...

Eu acho que você está interessado no que está por trás. Bem, o .NET Common Language Runtime faz distinção entre maiúsculas e minúsculas e o código VB.NET depende do tempo de execução; portanto, você pode ver que ele deve fazer distinção entre maiúsculas e minúsculas no tempo de execução, por exemplo, ao pesquisar variáveis ​​e métodos.

O compilador e editor do VB.NET permitem que você ignore isso - porque eles corrigem o caso no seu código.

Se você brinca com recursos dinâmicos ou ligação tardia (Option Strict Off), pode provar que o tempo de execução subjacente diferencia maiúsculas de minúsculas. Outra maneira de perceber isso é perceber que linguagens que diferenciam maiúsculas de minúsculas, como C #, usam o mesmo tempo de execução; portanto, o tempo de execução obviamente suporta a distinção entre maiúsculas e minúsculas.

EDIT Se você deseja tirar o IDE da equação, você sempre pode compilar a partir da linha de comando . Editar o seu código no bloco de notas por isso tem sse SSver o que o compilador faz.

EDIT Citação de Jeffrey Richter na página .NET Framework Design Guidelines 45.

Para ser claro, o CLR realmente diferencia maiúsculas de minúsculas. Algumas linguagens de programação, como o Visual Basic, não diferenciam maiúsculas de minúsculas. Quando o compilador do Visual Basic está tentando resolver uma chamada de método para um tipo definido em uma linguagem que diferencia maiúsculas de minúsculas como C #, o compilador (não o CLR) descobre o caso real do nome do método e o incorpora nos metadados. O CLR não sabe nada sobre isso. Agora, se você estiver usando reflexão para vincular a um método, as APIs de reflexão oferecem a capacidade de fazer pesquisas que não diferenciam maiúsculas de minúsculas. Essa é a extensão em que o CLR oferece distinção entre maiúsculas e minúsculas.

Parte do problema aqui é que você precisa dividir o idioma da experiência do IDE.

Como linguagem, o VB.NET certamente não diferencia maiúsculas de minúsculas em relação aos identificadores. Chamando DateTime.Parseedatetime.parse ligará exatamente ao mesmo código. E, diferentemente de linguagens como C #, não é possível definir métodos ou tipos que diferem apenas por caso.

Como um IDE, o VB.NET tenta preservar o caso dos identificadores existentes quando lista bastante um bloco de código. Listas bonitas ocorrem sempre que você sai da atual linha lógica de código. Nesse caso, você sai da segunda declaração de SS, a lista bonita percebe que existe um identificador existente com esse nome e o corrige para que tenha maiúsculas e minúsculas.

Esse comportamento, porém, é puramente feito como um valor agregado ao usuário. Não faz parte da linguagem principal.

O VB não diferencia maiúsculas de minúsculas, mas há exceções. Por exemplo, literais XML e compreensão diferenciam maiúsculas de minúsculas. As comparações de strings geralmente diferenciam maiúsculas de minúsculas, diferentemente do T-SQL, mas há uma opção de compilador para fazer comparações de strings sem distinção entre maiúsculas e minúsculas. E, é claro, existem os casos extremos ao lidar com herança, COM e Dynamic Language Runtime.

Sim, o compilador VB.NET trata identificadores de uma maneira que não diferencia maiúsculas de minúsculas. E sim, isso pode causar problemas quando consome assemblies que foram escritos em outro idioma ou usa componentes COM. O primeiro caso é coberto pela Common Language Specification . A regra relevante é:

Para que dois identificadores sejam considerados distintos, eles devem diferir mais do que apenas o caso.

O caso COM é tratado de maneira grosseira pelo construtor da biblioteca de tipos, o que força a identificação de maiúsculas e minúsculas de identificadores com o mesmo nome. Mesmo quando esses identificadores têm funções diferentes. Em outras palavras, um parâmetro de método com o nome "index" forçará um nome de método "Index" a ser recaseado para "index". Isso produziu bastante coçar a cabeça, como você pode imaginar :)

O VB preserva maiúsculas e minúsculas (no IDE), mas não diferencia maiúsculas de minúsculas . É como o sistema de arquivos do Windows, de certa forma. Hello.txt e hello.txt são considerados o mesmo nome de arquivo.

O IDE assume que a declaração de uma variável é o caso "correto" para essa variável e ajusta todas as instâncias dessa variável que correspondem à declaração. Isso é feito por razões atraentes e consistentes, mas não por funcionalidade.

Vi várias instâncias em que o caso não foi alterado automaticamente para corresponder à declaração e a instrução funciona da mesma forma. Você também pode usar qualquer editor de texto para escrever código que será compilado perfeitamente em diferentes casos.

Uma nota lateral:

A maioria das pessoas pensa de uma maneira que não diferencia maiúsculas de minúsculas. Quando vemos a palavra "cachorro", a palavra é traduzida em significado em nossas mentes. O significado da palavra não é baseado em maiúsculas e minúsculas (isto é, independentemente de se soletrar "DOG", "DoG" ou "dOG" ainda late.) OS COMPUTADORES veem as palavras como sacos discretos de bits. Maiúsculas e minúsculas são padrões de bits diferentes e, portanto, são diferentes.

Como a maioria dos programadores é humana, a insensibilidade a maiúsculas e minúsculas parece mais adaptada à maneira como as pessoas pensam e a sensibilidade a maiúsculas e minúsculas é mais sobre humanos, adaptando sua maneira de pensar às restrições de uma máquina.

Isso faz parte do editor que você está usando, eles podem se comportar de maneira diferente, mas o fato é que o Visual Basic realmente é uma linguagem que não diferencia maiúsculas de minúsculas. Então, sse SSsão iguais.

Dê uma olhada no tutorial básico do VB.NET para obter mais informações :)

Não sei se entendi você? VB não diferencia maiúsculas de minúsculas, portanto ss e SS são a mesma variável; portanto, o compilador reclama corretamente que você declarou novamente a variável.

Eu acho que as variáveis ​​não diferenciam maiúsculas de minúsculas, mas os nomes das funções.

Sim, o VB não diferencia maiúsculas de minúsculas. Às vezes, lança aqueles que não estão acostumados a isso um pouco.

Não é preciso tentar tanto no VB.NET para criar código com diferentes "ortografia" maiúsculas / minúsculas de um identificador. Alterar a caixa de um identificador no arquivo em que é declarado sem o uso da função "Renomear" não fará com que o nome seja atualizado em outros arquivos, embora editar qualquer linha que contenha o nome faça com que esteja em conformidade com a definição atual.

Dessa maneira, pode-se determinar que o VB.NET não faz distinção entre maiúsculas e minúsculas, mas disponibiliza os identificadores para o CLR, que podem usar essas informações de maneira que diferenciam maiúsculas de minúsculas.

Só posso oferecer isso, o que, como me lembro dos meus livros de programação no início dos anos 80, é que as linguagens sensíveis ao caso eram (naquele tempo) estritamente destinadas a reduzir erros no tempo de compilação. Ou seja, o "rigor" pretendia desenvolver uma disciplina de codificação com maior precisão. Como se constatou, a adição de uma rotulagem adequada de variáveis, classes, métodos, funções e qualquer outra coisa que você queira incluir nele também evoluiu.

Lembro-me de que quase todos esses livros incluíam um padrão recomendado para capitalização inicial, letras minúsculas etc. Como todos sabemos, grande parte disso foi descartada ou, devo dizer, ignorada na prática, exceto pelas casas de produção de última geração e Soluções CASE ou para aqueles que atingiram um nível de habilidade mais alto. Eu acho que todo mundo experimenta essa curva de aprendizado.

Dado o avanço desses idiomas e IDEs, a melhor pergunta é: qual idioma melhora meu tempo de desenvolvimento? Obviamente, se você não estiver familiarizado com cada um dos vários idiomas, suas opções são limitadas.

Vou tentar responder à sua segunda pergunta.

"isso é convincente o suficiente para eu considerar a possibilidade de mudar para C # se o caso do VB.NET estiver de alguma forma limitando o que eu poderia fazer com o código?"

Crie um WCF WebService usando C #. Crie um DataContract (1 classe). Um com a propriedade "string email". Outro com "string Email" como outra propriedade. Sua escolha é entender como email pessoal ou email do escritório. Ou pode estar em dois DataContracts diferentes.

Para C #, isso é bom. O serviço da web é criado bem. O programa AC # pode criar facilmente um WSDL e está tudo bem.

Agora tente criar um WSDL com VB (qualquer versão). Ele dirá "email" já está declarado e a geração do WSDL falha.

Como todo mundo, assumi que isso é uma desvantagem na linguagem VB. Mas!!!

Use o FxCOP e analise o código C # original. O FxCOP diz que usar email / email é um problema. Recomenda o uso de um nome diferente que suporte a insensibilidade do caso. Observe também que, na data, o .NET framework possui 106 linguagens de programação e há muitas linguagens com a distinção entre maiúsculas e minúsculas ativada. Estamos todos caminhando para a nuvem e queremos que nossos serviços sejam acessíveis por todas as plataformas / linguagens de programação.

Portanto, a diferenciação entre maiúsculas e minúsculas é a sua escolha no seu programa e, se você é do tipo C, gostaria. Se o programa for usado / acessado por outros programas que não sejam C, você precisará oferecer suporte à distinção entre maiúsculas e minúsculas, mas seu idioma é a sua escolha.

http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET http://www.vbrad.com/article.aspx?id=65

Ocultar símbolos (por exemplo, campo oculta local) também não faz distinção entre maiúsculas e minúsculas.

Aqui está um exemplo :

Public Class C
    Public Name As String

    Public Function M(name As String) As Boolean
        Return String.Equals(name, Name) ' case differs
    End Function
End Class

A saída do compilador VB.NET é descompilada para (e, portanto, equivalente a) o seguinte c #:

public class C
{
    public string Name;

    public bool M(string name)
    {
        return string.Equals(name, name); // both lowercase
    }
}

string.Equalsé passado o campo duas vezes. O local está oculto, independentemente do caso. A linguagem não diferencia maiúsculas de minúsculas.

Para referenciar explicitamente um membro, como este campo, você deve desreferenciar o membro via Me:

Return String.Equals(name, Me.Name) ' differentiate field from local

Eu não vi ninguém comentar sobre sua segunda pergunta explícita no final: "2: isso é convincente o suficiente para eu considerar a mudança para C # se o caso do VB.NET estiver de alguma forma limitando o que eu poderia fazer com o código?"

Eu prefiro a abordagem de mais opções que o C # permite que o programador escolha se limita as opções do programador. Eu prefiro o C #, mas apenas para a distinção entre maiúsculas e minúsculas, eu nem pensaria em aprender um idioma apenas porque é sensível a maiúsculas. todos os recursos são importantes e, quando observo as vantagens de ambos, C # e VB.NET, prefiro o C #. mas darei a você uma verdadeira perspectiva equilibrada, tendenciosa sim, porque tenho uma preferência, mas também serei honesto sobre as desvantagens do c #.

primeiro, os dois idiomas têm vantagens e desvantagens. as diferenças que você pode fazer em um idioma que não pode ser feito no outro estão diminuindo, pois, felizmente, a Microsoft está melhorando os dois idiomas, e eles parecem não estar mostrando parcialidade injusta em relação a um ou outro idioma.

quando o C # foi lançado, o VB não tinha seus comentários XML que você poderia colocar antes dos métodos, que eu adorava em C #. Eu odiava isso no VB.NET. mas vi ao longo dos anos que muitos recursos que não estão em um idioma são adicionados ao outro. (a mesma equipe de desenvolvedores da MS desenvolve C # e VB, portanto, faz sentido que os recursos se tornem bastante semelhantes.)

mas você perguntou o que o C # tem que o VB não tem. Aqui estão alguns em que consigo pensar imediatamente:

1: C # é mais conciso e leva menos digitação .. de muitas maneiras! Eu já vi estupidez falando quando a alegação oposta é feita, que o VB salva digitação. mas ouça as pessoas que lhe dizem que usam os dois idiomas e que raramente é usado por eles. eu uso ambos os c # eVB, C # em casa porque eu gosto (e quando trabalho com C # no trabalho) e minhas solicitações de trabalho mais recentes que eu uso VB e não C #. então, estou usando o VB com mais frequência agora (há cerca de 10 meses), mas, no meu testemunho pessoal, prefiro o C # e, em termos de digitação real, o VB é consideravelmente mais digitado. o exemplo que eu li onde alguém realmente tentou dizer que o VB era mais conciso, estava dando um exemplo 'with ...' com uma variável longa no with, então no VB, você poderia usar '.property'. isso é estupidez ao afirmar que o VB precisa de menos digitação. existem algumas coisas (e não apenas este exemplo) em que o VB é mais curto, mas muitas mais vezes quando o C # é mais conciso, na prática real.

mas a maior razão pela qual acredito que o C # é mais conciso, são as instruções "IF / THEN" do VB. se declarações são comuns. em C # não existe uma palavra 'then' para digitar! :) também todas as instruções 'end ...' recebem digitação, que em c #, geralmente é apenas uma chave de fechamento '}'. Eu li que algumas pessoas afirmam que essa maior verbosidade no VB.NET é uma vantagem para o VB, pois várias instruções / símbolos de bloco de fechamento podem ser aninhados e terminam imediatamente um ao lado do outro, mas discordo completamente. uma pessoa quase sempre pode escrever um programa melhor em C # ou VB do que outro programador, porque a próxima revisão de código poderia ser melhor projetada. isso se aplica aos 'confusos numerosos chavetas de fechamento em C #' mais se os blocos aninhados são todos do mesmo tipo, como vários IF's aninhados, o VB sofre o mesmo problema que em C #. isso não é uma vantagem no VB. Essa situação é precisamente a razão pela qual eu gostaria de comentar com o que meu símbolo ou declaração de fechamento se encaixa nos dois idiomas. sim, isso é mais detalhado, mas em qualquer idioma, você tem a opção de ser claro, o que é importante em casos específicos situacionais baseados em julgamento. Eu acho que a clareza do código é muito importante.

2: O VB não possui comentários de várias linhas. quando trabalhei com VB, não me importei. então eu fui para algumas linguagens no estilo C. agora estou de volta usando principalmente o VB.NET no trabalho e sinto falta deles. é apenas algo que você acha conveniente e precisa perder. :(

3: 'andalso' e 'orelse' do VB são bastante irritantes para digitar tudo isso quando, em C #, são simplesmente '&&' e '||'. novamente, menos digitação. isso não é raro no meu código em VB e C #. se alguma coisa, para funcionalidade, 'OR' vs 'OrElse' normalmente não importa, exceto que 'OrElse' é mais rápido para o computador, portanto, se um programador usar apenas 'Or' e 'And' no VB, ele produzirá um código menos ideal para alguém que gosta de clareza de código. 'Or' é muito mais fácil de deslizar do que 'OrElse'.

4: mais flexibilidade no posicionamento do código em C #. quando uma linha é longa e você deseja agrupá-la na próxima linha, eu odeio o 'controle' do VB.NET de reajuste do meu código. C # faz um pouco, mas acho mais útil em C #, onde no VB, é muito mais controlado. mas isso é mais do VB.NET IDE vs C # IDE do que da própria linguagem. mas não sei se você deseja os dois ou puramente os recursos de linguagem sem diferenças de IDE.

5: um que realmente sinto falta é apenas criar um novo bloco de código em C #, posso ter muita coisa acontecendo em um método e quero declarar uma variável em um bloco de código muito pequeno, mas não ter essa variável declarada fora desse bloco em o método inteiro. em C #, podemos apenas criar um novo bloco com '{' e finalizá-lo com '}'. O VB não possui esse recurso, mas a correspondência mais próxima é um bloco incondicional 'If True Then' e 'End If'. (observe o equivalente em VB.NET de 2 caracteres C # vs 18 caracteres novamente ... digitando mais em VB.)

6: auto incremento e operadores decremento: ++ e - como em myVariable++ou ++myVariableou as versões decremento equivalentes. isso é muito útil ... às vezes. Aqui está um exemplo de código real quando eu perdi muito o C #:

// C#:
while (txt.Length > x)
{
    thisChar = txt[x];
    if (charsAllowedWithoutLimit.Contains(thisChar)) { ++x; }
    else if (allowLettersWithoutLimit && char.IsLetter(thisChar)) { ++x; }
    else if ((x2 = charsAllowedWithLimit.IndexOf(thisChar)) >= 0)
    {
        ++x; if (++usedCountA[x2] > charAllowedLimit[x2]) { break; }
    }
    else { break; }
}

' VB.NET:
While (txt.Length > x)
    thisChar = txt(x)
    If (charsAllowedWithoutLimit.Contains(thisChar)) Then
        x += 1
    ElseIf (allowLettersWithoutLimit AndAlso Char.IsLetter(thisChar)) Then
        x += 1
    Else
        x2 = charsAllowedWithLimit.IndexOf(thisChar)
        If (x2 >= 0) Then
            x += 1
            usedCountA(x2) += 1S
            If usedCountA(x2) > charAllowedLimit(x2) Then Exit While
        Else
            Exit While
        End If
    End If
End While

E só para dar um exemplo MUITO bom de regras de C #, esse é mais código que eu escrevi recentemente:

// C#
public static bool IsNotWithin(this Byte   v, Byte   v1, Byte   v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this SByte  v, SByte  v1, SByte  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int16  v, Int16  v1, Int16  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int32  v, Int32  v1, Int32  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int64  v, Int64  v1, Int64  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }

public static bool IsWithin(this Byte   v, Byte   v1, Byte   v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this SByte  v, SByte  v1, SByte  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int16  v, Int16  v1, Int16  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int32  v, Int32  v1, Int32  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int64  v, Int64  v1, Int64  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }

' And the VB equivalent is a mess! Here goes:
<Extension()>
Public Function IsNotWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsNotWithin(v%, value1%, value2%) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsNotWithin(v&, value1&, value2&) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsNotWithin(v@, value1@, value2@) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsWithin(v%, value1%, value2%) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsWithin(v&, value1&, value2&) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsWithin(v@, value1@, value2@) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

Talvez isso seja prova suficiente de que o C # é mais conciso. Mas nem todos os programadores gostam de concisão. Alguns preferem ler "se a <b então ..." porque é mais natural para a linguagem humana. E tudo bem. Preferências são boas. Para mim, o esforço manual é um fator que eu valorizo ​​e acho que qualquer pessoa pode se acostumar a pensar nos símbolos de sua preferência, pois "if" e "then" são símbolos de um alfabeto e a declaração "if (condition)" do C #; " sintaxe também são símbolos. um está mais próximo da sintaxe de não programador do que o outro. Eu prefiro o conciso.

Também acho que a necessidade de usar 'c' após literais de caracteres no VB para torná-lo literal de caracteres, em vez de uma string, é irritante. Eu gosto da concisão do C # com muito mais. quando um método requer um literal de caractere, você precisa fornecer um caractere não uma string com um comprimento de caractere; portanto, às vezes você é forçado a usar ":"cno VB enquanto estiver no C # ':'. Eu acho que isso é nit-picking tho.

Para ser justo, eu vou dizer que há vantagens i gostam de VB como não ter de colocar parênteses vazios depois de chamadas de método, como Dim nameUpper$ = name.ToUpperInvariantem C # requer os parênteses vazios: string nameUpper = name.ToUpperInvariant(). ou o dobro que, como aparar também: Dim nameUpper$ = name.Trim.ToUpperInvariantvs string nameUpper = name.Trim().ToUpperInvariant(). Eu gosto do uso conciso do VB de como eu acabei de usar $acima para escurecer 'As String', onde o C # não possui esses atalhos. O VB possui esses atalhos para os tipos String, Inteiro, Longo, Decimal, Único e Duplo, mas a desvantagem é que é menos claro, então eu o uso com cautela. mas, no entanto, prefiro código conciso.

Bem, isso é apenas alguns pontos deste programador experiente e, como eu considero, este é o meu 'testemunho' de programação de C # vs VB. ambos são bons idiomas, na minha opinião. mas sim, eu ainda prefiro muito o c #.

ps Como planejo programar a maior parte da minha vida, aprendi a digitar usando o teclado mais eficiente: o teclado Dvorak, que leva cerca de 1/3 do esforço para digitar inglês do que em um teclado Qwerty. procure. talvez você queira mudar também. ;) tornou minha digitação 67% mais fácil! :) Encorajo qualquer pessoa a pensar fora da caixa e avaliar melhor eficiência no seu trabalho. O layout do teclado simplificado e o C # do Dvorak fizeram isso por mim. :)

PSS: eu compararia o Dvorak e o C # à métrica em oposição ao layout do teclado Qwerty e o VB às medidas empíricas. Dvorak, métrica e C # são apenas 'limpos'. Mas o VB não está muito atrás. Mas sofre com a necessidade de ser compatível com versões anteriores do código VB6 antigo e do código .NET anterior, como 'Or' vs 'OrElse' e 'IIF ()'.

Termino com cautela. Por favor, seja mais prudente do que ouvir pessoas que realmente não sabem do que estão falando. Metade de todos os contras contra VB e C # não sãomais qualquer problema, e as pessoas ainda postam sobre eles serem ignorantes sobre quais desvantagens realmente ainda existem no idioma. O melhor exemplo que consigo pensar é em comentários XML para métodos que usam apóstrofo triplo em VB ou símbolos de comentário de barra tripla em C #. Mas discuta por si mesmo se uma pessoa está falando por ignorância ou por experiência. Testemunho pessoal significa que eles sabem de sua experiência real. E depois que alguém tiver muita experiência, então anime seus ouvidos. Tenho mais de 10 anos de experiência em C # e VB. E tudo se resume a isso: ambas são (muito) boas linguagens. E a maioria das diferenças, você pode ver imediatamente dentro de 5 minutos após a leitura do código. Mas sim, outros recursos podem levar anos para encontrar uma desvantagem. E uma desvantagem que eu conheço (em C #), eu posso ' nem pense em uma situação da vida real onde seria útil. Portanto, talvez não seja uma desvantagem, afinal.

Feliz codificação!

O VB.NET não diferencia maiúsculas de minúsculas.

Exemplos:

1

Dim a As Integer
Dim A as Integer

2)

Sub b()
    'Some statement(s) here
End Sub
Sub B()
    'Some statement(s) here
End Sub

3)

Function c() As Integer
    'Some statement(s) here
End Function
Function C() As Integer
    'Some statement(s) here
End Function

Todo esse código lançará um erro de tempo de compilação .

Para o 1º exemplo, o erro será mostrado, dizendo "A variável local 'A' já está declarada no bloco atual".

Enquanto para o segundo e terceiro exemplo, será mostrado um erro dizendo "'Public Sub b ()' tem várias definições com assinaturas idênticas." e "'Função Pública c () Como Inteiro' 'possui várias definições com assinaturas idênticas.", respectivamente.

A partir desses erros, observe que os erros são lançados em posições diferentes para variáveis ​​e procedimentos / funções. Para variáveis, o erro é lançado na 2ª declaração, enquanto para procedimentos / funções é lançado na 1ª declaração / definição de código idêntico.

Como dito por um usuário em um comentário em algum lugar acima, o código VB.NET é continuamente verificado e / ou corrigido em segundo plano; você pode ver esse erro na janela "Lista de erros" no VS IDE. E como isso é um erro e não um aviso , o código não será compilado até que o erro seja resolvido.