validar upercase solo pasar net minusculas minuscula mayusculas mayuscula convert cambiar vb.net vba case-sensitive case-insensitive

vb.net - upercase - ¿VB realmente no distingue entre mayúsculas y minúsculas?



upercase vb net (13)

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

Pero aquí está mi pregunta: ¿dónde exactamente es insensible las mayúsculas y minúsculas 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 SS ya está declarada en el bloque actual ". En el VBA VBE, no genera 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 eso algo malo?)

¿Por qué estoy incluso haciendo esta pregunta?

He usado Visual Basic en muchos de sus dialectos desde hace 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 que C # ofrece que Visual Basic no (un opuesto sería VB.NET ofrece XML Literals ), entonces me gustaría para saber más sobre esa característica. Entonces, en este caso, a menudo se argumenta que los lenguajes C son sensibles a 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 exactamente es insensible a las mayúsculas / minúsculas de Visual Basic porque cada ejemplo en el editor de código se vuelve sensible a mayúsculas y minúsculas (lo que significa que el caso se corrige) ya sea que lo quiera o no y
  2. ¿Es esto lo suficientemente convincente para que considere mudarme a C # si el caso de VB.NET de alguna manera está limitando lo que podría hacer con el código?

La diferencia entre VBA y VB.NET es simplemente porque VB.NET compila continuamente en segundo plano. Obtendrá un error al compilar el VBA.

Como dice Jonathan , al programar se puede pensar en VB.NET como insensible a mayúsculas y minúsculas, además de las comparaciones de cadenas, XML y algunas otras situaciones ...

Creo que estás interesado en lo que hay debajo del capó. Bueno, .NET Common Language Runtime distingue entre mayúsculas y minúsculas , y el código VB.NET depende del tiempo de ejecución, por lo que puede ver que debe ser sensible a las mayúsculas y minúsculas en el tiempo de ejecución, por ejemplo, cuando busca variables y métodos.

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

Si juegas con funciones dinámicas o vinculación tardía (Option Strict Off) puedes demostrar 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 que distinguen entre mayúsculas y minúsculas, como C #, usan el mismo tiempo de ejecución, por lo que el tiempo de ejecución obviamente admite la distinción entre mayúsculas y minúsculas.

EDITAR Si desea sacar el IDE de la ecuación, siempre puede compilar desde la línea de comandos . Edite su código en el Notepad de Notepad para que tenga ss y SS y vea lo que hace el compilador.

EDIT Quote de Jeffrey Richter en .NET Framework Design Guidelines página 45.

Para ser claros, el CLR realmente 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 que distingue entre mayúsculas y minúsculas como C #, el compilador (no el CLR) averigua el caso real del nombre del método y lo incorpora en los metadatos. El CLR no sabe nada de esto. Ahora, si está utilizando la reflexión para enlazar 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.

No es necesario esforzarse tanto en VB.NET para crear código con diferentes "deletreos" en mayúsculas / minúsculas de un identificador. Cambiar la carcasa de un identificador en el archivo donde se ha declarado sin utilizar la función "Cambiar nombre" no hará que el nombre se actualice en otros archivos, aunque la edición de cualquier línea que contenga el nombre hará que se ajuste a la definición actual.

De esta forma, se puede determinar que VB.NET es, en su mayoría, insensible a mayúsculas y minúsculas, pero hace que el caso de los identificadores esté disponible para el CLR, que puede usar esa información en formas que distingan entre mayúsculas y minúsculas.

No estoy seguro de que te entiendo? 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 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í lo son.

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

prefiero el enfoque de más opciones que C # le permite al programador elegir si limita las opciones del programador. Yo prefiero mucho C #, pero solo por la distinción entre mayúsculas y minúsculas, ni siquiera creo que esté 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, parcial, sí, porque tengo una preferencia, pero seré sincero sobre las desventajas de C # también.

Primero, ambos idiomas tienen ventajas y desventajas. las diferencias que puede hacer en un idioma que no se pueden hacer en el otro son cada vez menos, ya que, afortunadamente, Microsoft está mejorando ambos idiomas, y parece que no muestran una parcialidad injusta hacia ninguno de los dos idiomas.

cuando C # apareció por primera vez, VB no tenía sus comentarios XML que se pudieran poner antes de los métodos, lo cual me encantó en C #. Odiaba eso en VB.NET. pero he visto a través 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 preguntaste qué C # tiene ese VB no. aquí hay algo que puedo pensar de inmediato:

1: C # es más conciso y requiere menos mecanografía .. ¡DE MUCHAS maneras! Incluso he visto hablar estupidez cuando se hace la afirmación opuesta, que VB guarda el tipeo. pero, por favor, escuche a las personas que le dicen que usan ambos idiomas, y ninguno de ellos es raramente utilizado por ellos. uso tanto C # como VB, C # en casa porque me gusta (y cuando trabajo con C # en el trabajo), y mi trabajo más reciente me pide que use VB y no C #. así que ahora estoy usando VB más frecuentemente (hace unos 10 meses), pero en mi testimonio personal, prefiero C #, y en términos de tipeo real, VB es considerablemente más tipador. el único ejemplo que he leído donde alguien realmente intentó decir que VB era más conciso, estaba dando un ejemplo ''con ...'' con una variable larga en el, así que en VB, podrías usar ''.property''. esto es estupidez al afirmar que VB necesita menos tipeo. hay algunas cosas (y no solo este ejemplo) donde VB es más corto, pero muchas más veces cuando C # es más conciso, en la práctica real.

pero la razón más grande por la que creo que C # es más conciso, es la verbosa declaración "IF / THEN" de VB. si las declaraciones son comunes. ¡en C # no hay palabra ''entonces'' para escribir! :) también todas las sentencias ''final ...'' toman tipeo que en c #, usualmente es solo un corchete de cierre ''}''. He leído que algunas personas afirman que esta más verbosidad en VB.NET es una ventaja para VB, ya que varios enunciados / símbolos de cierre de bloque pueden anidarse y terminar 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 del código podría diseñarse mejor. esto se aplica a los "numerosos refuerzos de cierre confusos en C # ''más si los bloques anidados son todos del mismo tipo, como varios FI anidados, entonces VB sufre el mismo problema que en C #. esto no es una ventaja en VB. Esta situación es precisamente la razón por la cual me gusta comentar lo que significa el símbolo de cierre o la 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 los casos específicos de situaciones basados ​​en el juicio. 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 estilo C ahora vuelvo a usar 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 tipeo. esto no es raro en mi código tanto en VB como en C #. en todo caso, para la funcionalidad, ''OR'' versus ''OrElse'' por lo general no importa, excepto ''OrElse'' es más rápido para la computadora, por lo que si un programador simplemente usa ''O'' y ''E'' en VB, produce menos código óptimo para alguien a quien le gusta la claridad del código ''O'' es mucho más fácil de desnatar que ''OrElse''.

4: más flexibilidad en la colocación del código en C #. cuando una línea es larga y quieres envolverla en la línea siguiente, odio el reajuste de "control" de mi código por parte de VB.NET. 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 solo las características del idioma sin diferencias IDE.

5: uno que echo de menos es simplemente crear un nuevo bloque de código en C #, puede que suceda mucho en un método y quiero declarar una variable en un bloque muy pequeño de código pero no tener esa variable declarada fuera de ese bloque en todo el método en C #, podemos simplemente crear un nuevo bloque con ''{'' y terminarlo con ''}''. VB no tiene dicha función, pero su coincidencia más cercana es un bloque incondicional "Si es verdadero, entonces" y "Fin si". (Nótese el carácter C de 2 caracteres contra el equivalente de VB.NET de 18 caracteres otra vez ... más escribiendo en VB).

6: operadores de autoincremento y decremento: ++ y - como en myVariable++ o ++myVariable o las versiones de decremento equivalentes. esto es muy útil ... a veces. aquí hay un ejemplo de código real cuando perdí mucho 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

Y solo para dar un MUY buen ejemplo donde las reglas de C #, este es más código que yo 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

Perhaps this is enuf evidence that C# is more concise. But not all programmers like conciseness. Some prefer to read "if a < b then ... " because it is more natural to their human language. And that''s just fine. Preferences are fine. For me, hand effort is a factor i value, and i think anyone can get used to thinking in any symbols they prefer, for "if" and "then" are symbols of an alphabet, and C#''s "if (condition) statement;" syntax are symbols too. one is just closer to non-programmer''s syntax than the other. i prefer the concise one.

I also think needing to use ''c'' after character literals in VB to make it a character literal rather than a string is annoying. I like C#''s conciseness with that much more. when a method requires a character literal, you need to provide a character not a string with one character length, so sometimes you are forced to use ":"c in VB while in C# it is '':'' . i think this is nit-picking tho.

To be fair, i will say there are advantages i like to VB like not having to put empty parentheses after method calls, like Dim nameUpper$ = name.ToUpperInvariant where C# requires the empty parentheses: string nameUpper = name.ToUpperInvariant() . or double that like trimming it too: Dim nameUpper$ = name.Trim.ToUpperInvariant vs string nameUpper = name.Trim().ToUpperInvariant() . I like VB''s concise use of how i just used $ above to dim it '' As String'' where C# does not have those shortcuts. VB has those shortcuts for String, Integer, Long, Decimal, Single, and Double types, but the disadvantage is it is less clear, so i use it with caution. but nevertheless, i prefer concise code.

Well, that''s just some thots from this seasoned programmer, and as i consider, this is my programming ''testimony'' of C# vs VB. both are nice languages tho, in my opinion. but yes, i still much prefer C#.

ps Since i plan to program for most of my life, i even re-learned to type using the most efficient keyboard: the Dvorak keyboard, which takes about 1/3 the effort to type English than on a Qwerty keyboard. look it up. maybe you might want to switch too. ;) it made my typing 67% easier! :) I encourage anyone to think outside the box and evaluate better efficiency in your work. The Dvorak Simplified Keyboard Layout and C# has done this for me. :)

PSS i would compare the Dvorak and C# to metric as opposed to the Qwerty keyboard layout and VB to the Empirial measurements. Dvorak, metric, and C# are just ''clean''. BUT VB is not really far behind. But it does suffer from needing to be backward compatible to old VB6 code and pre .NET code, like the ''Or'' vs ''OrElse'', and ''IIF()''.

I finish with a caution. Please be more prudent that listening to people who do not really know what they are talking about. Half of all the cons against both VB and C# are not any issue anymore, and people still post about them being ignorant about what disadvantages really still do exist in the language. The best example i can think of is XML comments for methods using triple apostrophe in VB or triple slash comment symbols in C#. But please discern for yourself whether a person is speaking from ignorance, or from experience. Personal testimony means they know from their real experience. And after someone has lots of experience in it, then perk up your ears. I have more than 10 years experience in both C# and VB. And it boils down to this: both are (very) good languages. And most the differences, you can see immediately within 5 minutes of reading code. But yes, other features it may take years to find a handicap. And one handicap that i''m aware of (in C#), I can''t even think of a real life situation where it would be useful. So perhaps it isn''t a handicap after all.

Happy coding!

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

Como lenguaje, VB.NET es ciertamente un caso insensible con respecto a los identificadores. Llamar a DateTime.Parse y datetime.parse se vinculará al mismo código exacto. Y a diferencia de idiomas como C #, no es posible definir métodos o tipos que difieran solo por caso.

Como un IDE, VB.NET intenta preservar el caso de los identificadores existentes cuando lista un bloque de código. Las listas bonitas se producen cada vez que se mueve fuera de la línea lógica actual de código. En este caso, se mueve fuera de la segunda declaración de SS , el bonito lister nota que hay un identificador existente con ese nombre y lo corrige para que tenga un caso coincidente.

Sin embargo, este comportamiento se realiza exclusivamente como un valor agregado del usuario. No es parte del lenguaje central.

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

Sí, el compilador 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 ensamblajes que fueron escritos en otro idioma o usa componentes COM. El primer caso está cubierto por la especificación de lenguaje común . La regla relevante es:

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

El caso de COM es bastante crudamente atendido por el constructor de bibliotecas de tipo, 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 un nombre de método "Índice" a volver a catalogarse como "índice". Eso ha producido bastante rasguño en la cabeza, como se puede imaginar :)

Solo puedo ofrecer esto, que según recuerdo de mis libros de texto de programación de principios de los 80, es que los lenguajes senstive eran, (en ese momento) estrictamente destinados a reducir los errores de tiempo de compilación. Es decir, el "rigor" tenía la intención de desarrollar una disciplina de codificación de mayor precisión. Como resultado, la adición de un etiquetado adecuado de variables, clases, métodos, funciones y cualquier otra cosa que desees introducir evolucionó también.

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

Dado el avance de estos lenguajes e IDE, la mejor pregunta es, ¿qué lenguaje mejora mi tiempo de desarrollo? Por supuesto, si no está familiarizado con cada una de las diferentes langs, sus opciones son limitadas.

Trataré de responder tu segunda pregunta.

"¿Es esto lo suficientemente convincente para que considere mudarme a C # si el caso de VB.NET de alguna manera limita 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 para entender como correo electrónico personal o correo electrónico de la 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á que "correo electrónico" ya está declarado y la generación de WSDL falla.

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

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

Por lo tanto, ser sensible a las mayúsculas y minúsculas es tu elección dentro de tu programa y si eres un chico de C, te gustaría. Si el programa va a ser utilizado / accedido por otros programas que no sean C, necesita admitir la insensibilidad a las mayúsculas y minúsculas, pero su idioma es el que usted elija.

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

VB generalmente no distingue entre mayúsculas y minú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 T-SQL, pero hay un cambio de compilador para hacer que las comparaciones de cadenas no sean sensibles a las mayúsculas y minúsculas. Y, por supuesto, existen los casos límite cuando se trata de herencia, COM y Dynamic Language Runtime.

VB conserva 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 asume 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 gusto y por razones de coherencia, pero no por funcionalidad.

He visto varios casos en los que el caso no se modificó 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 lateral:

La mayoría de las personas piensan de una manera que no distingue entre 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 lo deletrean "PERRO", "DoG" o "PERRO" todavía ladra). LAS 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.

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

VB.NET is case-INsensitive.

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

These all code will throw a COMPILE-TIME ERROR .

For the 1st example, error will be shown, saying "Local variable ''A'' is already declared in the current block.".

While for the 2nd and 3rd example, error will be shown saying "''Public Sub b()'' has multiple definitions with identical signatures." and "''Public Function c() As Integer'' has multiple definitions with identical signatures.", respectively.

From these errors, note that the errors are thrown at different positions for variables and procedures/functions. For variables, error is thrown at 2nd declaration while for procedures/functions it is thrown at 1st declaration/definition of identical code.

As said by a user in a comment somewhere above, the VB.NET code is continuously checked and/or corrected in background; you can see this error in "Error List" window in VS IDE. And as this is AN ERROR and NOT A WARNING , the code will not compile until error is resolved.