¿VB realmente no distingue entre mayúsculas y minúsculas?

No estoy tratando de comenzar una discusión aquí, pero por alguna razón, generalmente se dice que Visual Basic no distingue entre mayúsculas y minúsculas y los lenguajes C no lo son (y de alguna manera eso es algo bueno).

Pero aquí está mi pregunta: ¿Dónde es exactamente la mayúscula y minúscula de Visual Basic? Cuando escribo ...

Dim ss As String
Dim SS As String

... en el IDE de Visual Studio 2008 o Visual Studio 2010 , el segundo tiene una advertencia de " La variable local SSya está declarada en el bloque actual ". En el VBA VBE, no elimina inmediatamente un error, sino que simplemente corrige automáticamente el caso.

¿Me estoy perdiendo algo aquí con este argumento de que Visual Basic no distingue entre mayúsculas y minúsculas? (Además, si sabe o le interesa responder, ¿por qué sería algo malo?)

¿Por qué estoy haciendo esta pregunta?

He usado Visual Basic en muchos de sus dialectos durante años, a veces como aficionado, a veces para programas relacionados con pequeñas empresas en un grupo de trabajo. A partir de los últimos seis meses, he estado trabajando en un gran proyecto, mucho más grande de lo que esperaba. Gran parte del código fuente de muestra está en C #. No tengo ningún deseo ardiente de aprender C #, pero si hay cosas que me estoy perdiendo en las ofertas de C # que Visual Basic no (lo contrario sería VB.NET ofrece Literales XML ), entonces me gustaría para saber más sobre esa característica. Entonces, en este caso, a menudo se argumenta que los lenguajes C distinguen entre mayúsculas y minúsculas y eso es bueno y Visual Basic no distingue entre mayúsculas y minúsculas y eso es malo. Me gustaría saber...

1. ¿Cómo se distingue entre mayúsculas y minúsculas de Visual Basic ya que cada ejemplo en el editor de código se distingue entre mayúsculas y minúsculas (lo que significa que el caso se corrige) si lo quiero o no?
2. ¿Es esto lo suficientemente convincente como para considerar pasar a C # si el caso de VB.NET limita de alguna manera lo que podría hacer con el código?

La diferencia entre VBA y VB.NET es solo porque VB.NET se compila continuamente en segundo plano. Obtendrá un error cuando compile el VBA.

Como dice Jonathan , cuando se programa puede pensar que VB.NET no distingue entre mayúsculas y minúsculas, aparte de las comparaciones de cadenas, XML y algunas otras situaciones ...

Creo que te interesa lo que hay debajo del capó. Bueno, .NET Common Language Runtime distingue entre mayúsculas y minúsculas , y el código VB.NET se basa en el tiempo de ejecución, por lo que puede ver que debe distinguir entre mayúsculas y minúsculas en tiempo de ejecución, por ejemplo, cuando busca variables y métodos.

El compilador y editor de VB.NET le permite ignorar eso, porque corrigen el caso en su código.

Si juega con características dinámicas o enlace tardío (Opción estrictamente desactivada), puede probar que el tiempo de ejecución subyacente distingue entre mayúsculas y minúsculas. Otra forma de ver eso es darse cuenta de que los lenguajes sensibles a mayúsculas y minúsculas como C # usan el mismo tiempo de ejecución, por lo que el tiempo de ejecución obviamente admite mayúsculas y minúsculas.

EDITAR Si desea eliminar el IDE de la ecuación, siempre puede compilar desde la línea de comandos . Editar el código en el Bloc de notas por lo que tiene ssy SSver qué hace el compilador.

EDITAR Cita de Jeffrey Richter en .NET Framework Design Guidelines page 45.

Para ser claros, el CLR distingue entre mayúsculas y minúsculas. Algunos lenguajes de programación, como Visual Basic, no distinguen entre mayúsculas y minúsculas. Cuando el compilador de Visual Basic intenta resolver una llamada de método a un tipo definido en un lenguaje sensible a mayúsculas y minúsculas como C #, el compilador (no el CLR) descubre el caso real del nombre del método y lo incrusta en metadatos. El CLR no sabe nada de esto. Ahora, si está utilizando la reflexión para unirse a un método, las API de reflexión ofrecen la posibilidad de realizar búsquedas que no distinguen entre mayúsculas y minúsculas. Esta es la medida en que el CLR ofrece insensibilidad a mayúsculas y minúsculas.

Parte del problema aquí es que necesita dividir el idioma de la experiencia IDE.

Como lenguaje, VB.NET sin duda distingue entre mayúsculas y minúsculas con respecto a los identificadores. Llamando DateTime.Parsey datetime.parsese unirá al mismo código exacto. Y a diferencia de los lenguajes como C #, no es posible definir métodos o tipos que difieran solo según el caso.

Como IDE, VB.NET intenta preservar el caso de los identificadores existentes cuando enumera un bloque de código. Las listas bonitas se producen cada vez que se sale de la línea lógica de código actual. En este caso, se sale de la segunda declaración de SS, la bonita lista nota que hay un identificador existente con ese nombre y lo corrige para que coincida con mayúsculas y minúsculas.

Sin embargo, este comportamiento se realiza únicamente como un valor agregado para el usuario. No es parte del lenguaje central.

VB es sobre todo sensible a mayúsculas, pero hay excepciones. Por ejemplo, los literales XML y la comprensión distinguen entre mayúsculas y minúsculas. Las comparaciones de cadenas generalmente distinguen entre mayúsculas y minúsculas, a diferencia de decir T-SQL, pero hay un interruptor del compilador para hacer que las comparaciones de cadenas no distingan entre mayúsculas y minúsculas. Y, por supuesto, hay casos extremos cuando se trata de herencia, COM y Dynamic Language Runtime.

Sí, el compilador de VB.NET trata los identificadores de una manera que no distingue entre mayúsculas y minúsculas. Y sí, eso puede causar problemas cuando consume ensamblados que se escribieron en otro idioma o usa componentes COM. El primer caso está cubierto por la Especificación del idioma común . La regla relevante es:

Para que dos identificadores se consideren distintos, deben diferir en algo más que su caso.

El constructor de la biblioteca de tipos se ocupa de manera bastante cruda del caso COM, obliga a que la carcasa de los identificadores con el mismo nombre sea idéntica. Incluso cuando esos identificadores tienen roles diferentes. En otras palabras, un parámetro de método con el nombre "índice" obligará a que el nombre de un método "Índice" se vuelva a colocar en "índice". Eso ha producido bastante rascarse la cabeza, como te puedes imaginar :)

VB preserva las mayúsculas y minúsculas (en el IDE) pero no distingue entre mayúsculas y minúsculas . Es como el sistema de archivos de Windows de alguna manera. Hello.txt y hello.txt se consideran el mismo nombre de archivo.

El IDE supone que la declaración de una variable es el caso "correcto" para esa variable y ajusta cada instancia de esa variable para que coincida con la declaración. Lo hace por razones visuales y de consistencia, pero no por su funcionalidad.

He visto varios casos en los que el caso no se cambió automáticamente para que coincida con la declaración, y la declaración funciona de la misma manera. También puede usar cualquier editor de texto para escribir código que compilará bien en diferentes casos.

Una nota al margen:

La mayoría de las PERSONAS piensan sin distinción de mayúsculas y minúsculas. Cuando vemos la palabra "perro", la palabra se traduce en significado en nuestras mentes. El significado de la palabra no se basa en el caso (es decir, independientemente de si se escribe "PERRO", "DoG" o "PERRO" todavía ladra). COMPUTADORAS ven las palabras como bolsas discretas de bits. Mayúsculas y minúsculas son patrones de bits diferentes y, por lo tanto, son diferentes.

Como la mayoría de los programadores son humanos, la insensibilidad a las mayúsculas y minúsculas parece más adaptada a la forma en que las personas piensan y la sensibilidad a las mayúsculas y minúsculas se trata más de que los humanos adapten su forma de pensar a las limitaciones de una máquina.

Esto es parte del editor que está utilizando, pueden comportarse de manera diferente, pero el hecho es que Visual Basic realmente no distingue entre mayúsculas y minúsculas. Entonces, ssy SSson lo mismo.

Consulte el tutorial de conceptos básicos de VB.NET para obtener más información :)

No estoy seguro de entenderte? VB no distingue entre mayúsculas y minúsculas, por lo que ss y SS son la misma variable, por lo que el compilador se queja correctamente de que usted ha vuelto a declarar la variable.

Creo que las variables no distinguen entre mayúsculas y minúsculas, pero los nombres de las funciones sí.

Sí, VB no distingue entre mayúsculas y minúsculas. A veces arroja a los que no están acostumbrados por un poco de bucle.

Uno no tiene que esforzarse tanto en VB.NET para crear código con diferentes "ortografías" mayúsculas / minúsculas de un identificador. Cambiar la carcasa de un identificador en el archivo donde se declara sin usar la función "Cambiar nombre" no hará que el nombre se actualice en otros archivos, aunque editar cualquier línea que contenga el nombre hará que se ajuste a la definición actual.

De esta manera, se puede determinar que VB.NET no distingue entre mayúsculas y minúsculas, pero sí pone a disposición del CLR el caso de identificadores que pueden utilizar esa información de manera sensible a mayúsculas y minúsculas.

Solo puedo ofrecer esto, que como recuerdo de mis libros de texto de programación a principios de los años 80, es que los lenguajes sensibles (en ese momento) tenían la estricta intención de reducir los errores de tiempo de compilación. Es decir, el "rigor" tenía por objeto desarrollar una disciplina de codificación de mayor precisión. Como ha resultado, la adición de un etiquetado adecuado de variables, clases, métodos, funciones y cualquier otra cosa que desee incluir también evolucionó.

Recuerdo que casi todos esos libros incluían un patrón recomendado para capitalizar con mayúscula, minúsculas, etc. Como todos sabemos, gran parte de eso se ha descartado o debería decir, ignorado en la práctica, salvo para las casas de producción de alta gama, y Soluciones CASE, o para aquellos que han alcanzado un nivel de habilidad más alto. Creo que todos experimentan esta curva de aprendizaje.

Dado el avance de estos idiomas e IDE, la mejor pregunta es, ¿qué idioma mejora mi tiempo de desarrollo? Por supuesto, si no está familiarizado con cada uno de los diversos idiomas, sus opciones son limitadas.

Trataré de responder tu segunda pregunta.

"¿Es esto lo suficientemente convincente como para considerar pasar a C # si el caso VB.NET limita de alguna manera lo que podría hacer con el código?"

Cree un servicio web WCF usando C #. Crear un DataContract (1 clase). Uno con la propiedad "cadena de correo electrónico". Otro con "cadena de correo electrónico" como otra propiedad. Su elección de entender como correo electrónico personal o correo electrónico de oficina. O podría estar en dos DataContracts diferentes.

Para C # esto está bien. El servicio web está bien creado. El programa AC # puede crear fácilmente un WSDL y todo está bien.

Ahora intente crear un WSDL con VB (cualquier versión). Dirá "correo electrónico" ya está declarado y la generación WSDL falla.

Como todos, asumí que esto es un inconveniente en el lenguaje VB. ¡¡¡Pero!!!

Use FxCOP y analice el código C # original. FxCOP dice que usar el correo electrónico / correo electrónico es un problema. Recomienda usar un nombre diferente que respalde la insensibilidad a mayúsculas y minúsculas. También tenga en cuenta que a la fecha .NET Framework tiene 106 lenguajes de programación y hay muchos lenguajes con mayúsculas y minúsculas en ON. Todos nos estamos moviendo hacia la nube y queremos que nuestros servicios sean accesibles para todas las plataformas / lenguajes de programación.

Por lo tanto, ser sensible a mayúsculas y minúsculas es su elección dentro de su programa y si es un tipo C le gustaría. Si el programa va a ser utilizado / accedido por otros programas que no sean C, debe admitir la insensibilidad a mayúsculas y minúsculas, pero su idioma es su elección.

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

La ocultación de símbolos (p. Ej., Campo de ocultación local) también distingue entre mayúsculas y minúsculas.

Aquí hay un ejemplo :

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

La salida del compilador VB.NET se descompila en (y, por lo tanto, equivalente a) el siguiente C #:

public class C
{
    public string Name;

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

string.EqualsSe pasa el campo dos veces. Lo local está oculto, independientemente del caso. El lenguaje no distingue entre mayúsculas y minúsculas.

Para hacer referencia explícita a un miembro, como este campo, debe eliminar la referencia del miembro a través de Me:

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

No he visto a nadie comentar sobre su segunda pregunta explícita al final: "2: ¿es esto lo suficientemente convincente como para considerar pasar a C # si el caso de VB.NET limita de alguna manera lo que podría hacer con el código?"

prefiero el enfoque de más opciones que C # le permite al programador elegir si limitar las opciones del programador. prefiero C #, pero solo por mayúsculas y minúsculas, ni siquiera lo pensaría cerca de aprender un idioma solo porque distingue entre mayúsculas y minúsculas. todas las características son lo que importa, y cuando miro las ventajas de ambos, C # y VB.NET, prefiero C #. pero le daré una perspectiva verdaderamente equilibrada, sesgada, sí, porque tengo preferencia, pero también seré honesto acerca de las desventajas de C #.

En primer lugar, ambos idiomas tienen ventajas y desventajas. Las diferencias que puede hacer en un idioma que no se pueden hacer en el otro están disminuyendo ya que, afortunadamente, Microsoft está mejorando ambos idiomas, y parece que no muestran parcialidad injusta hacia ninguno de los dos idiomas.

cuando salió C # por primera vez, VB no tenía sus comentarios XML que podía poner antes de los métodos, lo que me encantó en C #. Odiaba eso en VB.NET. pero he visto a lo largo de los años, que muchas características que no están en un idioma se agregan al otro. (el mismo equipo de desarrolladores de MS desarrolla tanto C # como VB, por lo que tiene sentido que las características se vuelvan bastante similares).

pero usted preguntó qué tiene C # que VB no tiene. Aquí hay algunos que puedo pensar de inmediato:

1: C # es más conciso y requiere menos escritura ... ¡de MUCHAS maneras! Incluso he visto estupidez al hablar cuando se hace la afirmación opuesta, que VB guarda la escritura. pero por favor escuche a las personas que le dicen que usan ambos idiomas, y que rara vez usan ninguno de ellos. Yo uso C # yVB, C # en casa porque me gusta (y cuando trabajo con C # en el trabajo), y mi trabajo más reciente solicita que use VB y no C #. así que ahora uso VB con más frecuencia (desde hace aproximadamente 10 meses), pero en mi testimonio personal, prefiero C #, y en términos de mecanografía real, VB es mucho más mecanografía. El único ejemplo que he leído en el que alguien realmente trató de decir que VB era más conciso, fue dar un ejemplo 'con ...' con una variable larga en el, así que en VB, podría usar '.property'. Esto es una estupidez al afirmar que VB necesita menos tipeo. Hay algunas cosas (y no solo este ejemplo) donde VB es más corto, pero muchas veces más cuando C # es más conciso, en la práctica real.

pero la razón más importante por la que creo que C # es más conciso es la declaración detallada de IF / THEN de VB. Si las declaraciones son comunes. en C # no hay una palabra 'entonces' para escribir. :) también todas las declaraciones 'end ...' toman el tipo de letra que en c #, generalmente es solo una llave de cierre '}'. He leído que algunas personas afirman que esto es más detallado en VB.NET es una ventaja para VB ya que varias declaraciones / símbolos de bloque de cierre pueden anidarse y terminar inmediatamente uno al lado del otro, pero no estoy de acuerdo. una persona casi siempre puede escribir un programa mejor en C # o VB que otro programador porque la próxima revisión de código podría diseñarse mejor. esto se aplica a los 'confusos numerosos corchetes de cierre en C #' más si los bloques anidados son todos del mismo tipo que varios IF anidados, entonces VB sufre el mismo problema que tiene en C #. Esto no es una ventaja en VB. Esta situación es precisamente la razón por la que me gusta comentar con qué se corresponde mi símbolo de cierre o declaración de cierre en ambos idiomas. Sí, esto es más detallado, pero en cualquier idioma, tiene la opción de ser claro, lo cual es importante en casos específicos basados ​​en el juicio y la situación. Creo que la claridad del código es bastante importante.

2: VB no tiene comentarios de varias líneas. cuando trabajé con VB no me importó. luego fui a algunos lenguajes de estilo C. ahora estoy de vuelta principalmente usando VB.NET en el trabajo, y los extraño. es algo que le parece conveniente y luego tiene que perder. :(

3: 'andalso' y 'orelse' de VB es bastante molesto escribir todo eso cuando en C # es simplemente '&&' y '||'. de nuevo, menos mecanografía. Esto no es raro en mi código tanto en VB como en C #. en todo caso, para la funcionalidad, 'OR' frente a 'OrElse' generalmente no importa, excepto que 'OrElse' es más rápido para la computadora, por lo que si un programador solo usa 'O' y 'Y' en VB, entonces produce un código menos óptimo para Alguien a quien le gusta la claridad del código. 'O' es mucho más fácil de leer que 'OrElse'.

4: más flexibilidad en la colocación de código en C #. cuando una línea es larga y desea ajustarla en la siguiente línea, odio el reajuste 'control' de VB.NET de mi código. C # lo hace un poco, pero lo encuentro más útil en C #, donde en VB, es mucho más controlador. pero esto es más del VB.NET IDE vs C # IDE en lugar del lenguaje en sí. pero no sé si quieres ambas o las características del lenguaje sin diferencias IDE.

5: uno que realmente extraño es simplemente crear un nuevo bloque de código en C #, es posible que suceda muchas cosas en un método y quiero declarar una variable en un bloque de código muy pequeño, pero no tener esa variable declarada fuera de ese bloque en Todo el método. en C #, podemos crear un nuevo bloque con '{' y finalizarlo con '}'. VB no tiene tal característica, pero su coincidencia más cercana es un bloque incondicional 'If True Then' y 'End If'. (tenga en cuenta el equivalente de 2 caracteres C # frente a 18 caracteres VB.NET de nuevo ... más escribir en VB.)

6: operadores de auto incremento y decremento: ++ y - como en myVariable++o en ++myVariablelas versiones de decremento equivalentes. Esto es muy útil ... a veces. Aquí hay un ejemplo de código real cuando perdí C # en gran medida:

// 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

Y solo para dar un MUY buen ejemplo donde C # gobierna, este es más código que personalmente escribí recientemente:

// 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

Quizás esto sea evidencia suficiente de que C # es más conciso. Pero no a todos los programadores les gusta la concisión. Algunos prefieren leer "si a <b entonces ..." porque es más natural para su lenguaje humano. Y eso está bien. Las preferencias están bien. Para mí, el esfuerzo manual es un factor que valoro, y creo que cualquiera puede acostumbrarse a pensar en cualquier símbolo que prefiera, ya que "if" y "then" son símbolos de un alfabeto y C # 's "declaración if (condición)"; la sintaxis también son símbolos. uno está más cerca de la sintaxis del no programador que el otro. Prefiero el conciso.

También creo que la necesidad de usar 'c' después de los literales de caracteres en VB para convertirlo en un literal de caracteres en lugar de una cadena es molesto. Me gusta la concisión de C # con eso mucho más. cuando un método requiere un carácter literal, debe proporcionar un carácter, no una cadena, con una longitud de carácter, por lo que a veces se ve obligado a usarlo ":"cen VB mientras está en C # ':'. Creo que esto es muy difícil.

Para ser justos, he de decir que hay ventajas me gusta a VB como no tener que poner paréntesis vacíos después de las llamadas de método, al igual Dim nameUpper$ = name.ToUpperInvariantque C # requiere los paréntesis vacíos: string nameUpper = name.ToUpperInvariant(). o el doble que al igual que el recorte también: Dim nameUpper$ = name.Trim.ToUpperInvariantvs string nameUpper = name.Trim().ToUpperInvariant(). Me gusta el uso conciso de VB de cómo acabo de usar $arriba para atenuarlo 'Como cadena' donde C # no tiene esos accesos directos. VB tiene esos accesos directos para String, Integer, Long, Decimal, Single y Double, pero la desventaja es que es menos claro, así que lo uso con precaución. pero sin embargo, prefiero un código conciso.

Bueno, eso es solo algunas de las cosas de este programador experimentado, y como considero, este es mi 'testimonio' ​​de programación de C # vs VB. ambos son buenos idiomas, en mi opinión. pero sí, todavía prefiero C #.

ps Como planeo programar la mayor parte de mi vida, incluso aprendí a escribir con el teclado más eficiente: el teclado Dvorak, que requiere aproximadamente 1/3 del esfuerzo para escribir en inglés que en un teclado Qwerty. búscalo tal vez también quieras cambiar. ;) ¡me facilitó la escritura un 67%! :) Animo a cualquiera a pensar fuera de la caja y evaluar una mejor eficiencia en su trabajo. El diseño de teclado simplificado de Dvorak y C # lo han hecho por mí. :)

PSS compararía el Dvorak y C # con la métrica en lugar de la distribución del teclado Qwerty y el VB con las medidas empíricas. Dvorak, métrica y C # son simplemente 'limpios'. PERO VB no está muy lejos. Pero sufre la necesidad de ser compatible con versiones anteriores del antiguo código VB6 y el código pre .NET, como 'Or' vs 'OrElse' y 'IIF ()'.

Termino con precaución. Sea más prudente que escuchar a las personas que realmente no saben de qué están hablando. La mitad de todas las desventajas contra VB y C # no soncualquier problema, y ​​la gente todavía publica acerca de que ignoran qué desventajas realmente existen en el idioma. El mejor ejemplo que se me ocurre son los comentarios XML para los métodos que utilizan el triple apóstrofe en VB o los símbolos de comentario de triple barra en C #. Pero discierna por sí mismo si una persona está hablando por ignorancia o por experiencia. Testimonio personal significa que saben de su experiencia real. Y después de que alguien tenga mucha experiencia en él, entonces levanta tus oídos. Tengo más de 10 años de experiencia en C # y VB. Y se reduce a esto: ambos son (muy) buenos idiomas. Y la mayoría de las diferencias, puede ver inmediatamente dentro de los 5 minutos de leer el código. Pero sí, otras características pueden llevar años para encontrar una discapacidad. Y una desventaja que conozco (en C #), puedo ' Incluso piense en una situación de la vida real en la que sería útil. Entonces, tal vez no sea una desventaja después de todo.

¡Feliz codificación!

VB.NET es sensible a mayúsculas y minúsculas.

Ejemplos:

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 este código arrojará un ERROR DE TIEMPO DE COMPILACIÓN .

Para el primer ejemplo, se mostrará un error que dice "La variable local 'A' ya está declarada en el bloque actual".

Mientras que para el segundo y tercer ejemplo, se mostrará un error que dice "'Public Sub b ()' tiene múltiples definiciones con firmas idénticas". y "'Función pública c () como entero' tiene múltiples definiciones con firmas idénticas", respectivamente.

A partir de estos errores, tenga en cuenta que los errores se lanzan en diferentes posiciones para variables y procedimientos / funciones. Para las variables, el error se genera en la segunda declaración, mientras que para los procedimientos / funciones se genera en la primera declaración / definición de código idéntico.

Como dijo un usuario en un comentario en alguna parte anterior, el código VB.NET se verifica y / o corrige continuamente en segundo plano; puede ver este error en la ventana "Lista de errores" en VS IDE. Y como esto es un ERROR y NO UNA ADVERTENCIA , el código no se compilará hasta que se resuelva el error.