significa sensitive sensible que minusculas mayusculas insensitive c# case-sensitive

c# - sensitive - ¿Por qué la gente le gusta la sensibilidad de mayúsculas y minúsculas



key sensitive (25)

Me pregunto por qué a las personas les gusta la sensibilidad de mayúsculas y minúsculas en un lenguaje de programación. No estoy tratando de iniciar una guerra de llamas solo curiosidad eso es todo.
Personalmente, nunca me ha gustado porque mi productividad baja cuando pruebo un lenguaje que tiene sensibilidad a las mayúsculas y minúsculas, claro que me estoy calentando / acostumbrando lentamente ahora que estoy usando C # y F # mucho más que Solía.

Entonces, ¿por qué te gusta?

Aclamaciones


Consistencia. El código es más difícil de leer si "foo", "Foo", "fOO" y "fOo" se consideran idénticos.

ALGUNAS PERSONAS LE ESCRIBIRAN TODO EN TODOS LOS TAPONES, HACIENDO QUE TODO LO MENOS LEYENDO.

La distinción entre mayúsculas y minúsculas facilita el uso del "mismo nombre" de diferentes maneras, de acuerdo con una convención de mayúsculas, por ejemplo,

Foo foo = ... // "Foo" is a type, "foo" is a variable with that type


Creo que es importante que comprenda la diferencia entre qué sensibilidad de caso es y qué legibilidad es para responder adecuadamente a esto. Aunque es útil tener diferentes estrategias de envoltura, puede tenerlas en un idioma que no distinga entre mayúsculas y minúsculas.

Por ejemplo, foo puede usarse para una variable y FOO como una constante en java y VB. Existe la menor diferencia de que VB te permitirá escribir FOo más adelante, pero esto es principalmente cuestión de legibilidad y con suerte se soluciona mediante algún tipo de finalización de código.

Lo que puede ser extremadamente útil es cuando quieres tener instancias de tus objetos. Si utiliza una convención de nomenclatura coherente, puede ser muy fácil ver de dónde provienen sus objetos.

Por ejemplo: FooBar fooBar = new FooBar ();

Cuando solo se necesita un objeto de un tipo, la legibilidad aumenta significativamente, ya que es evidente de forma inmediata qué es el objeto. Cuando se necesitan varias instancias, obviamente tendrá que elegir nuevos nombres (afortunadamente significativos), pero en secciones de códigos pequeños tiene mucho sentido usar el nombre de clase con un primer carácter en minúscula en lugar de un sistema como myFooBar, x o algún otro valor arbitrario que olvidará lo que hace.

Por supuesto, todo esto es una cuestión de contexto, sin embargo, en este contexto, diría que 9 de cada 10 veces vale la pena.


Creo que impone consistencia, lo que mejora la legibilidad del código y permite que tu ojo analice mejor las piezas.

class Doohickey { public void doSomethingWith(string things) { print(things); } }

El uso de convenciones de envoltura hace que el código parezca muy estandarizado para cualquier programador. Puede elegir clases, tipos, métodos fácilmente. Sería mucho más difícil de hacer si alguien pudiera capitalizarlo de alguna manera:

Class DOOHICKEY { Public Void dosomethingwith(string Things) { Print(things); } }

No quiere decir que la gente escriba un código feo, pero la forma en que las reglas de mayúsculas y puntuación hacen que la escritura sea más fácil de leer es más fácil, los estándares de mayúsculas y minúsculas hacen que el código sea más fácil de leer.


En los programas, hay algo que decir acerca de la distinción entre mayúsculas y minúsculas, por ejemplo, tener una propiedad pública Foo y un campo privado / protegido correspondiente foo. Con IntelliSense no es muy difícil no cometer errores.

Sin embargo, en un SO, la sensibilidad de mayúsculas y minúsculas es simplemente una locura Realmente no quiero tener un archivo Foo y Foo y FOO en el mismo directorio. Esto me motiva cada vez que hago cosas de nix.


En mi humilde opinión, es una cuestión de hábito. Cualquiera que sea que estés acostumbrado te parecerá natural y correcto.

Puede encontrar muchas justificaciones sobre por qué es bueno o malo, pero ninguno de ellos contiene mucha agua. P.ej:

  • Obtienes más identificadores posibles, ej. foo vs Foo vs FOO .
  • Pero tener identificadores que difieren solo en el caso no es una buena idea
  • Puede codificar type-info en un nombre (por ejemplo, FooBar = typename, fooBar = function, foo_bar = variable, FOO_BAR = macro)
  • Pero puedes hacerlo de todos modos con la notación húngara

Es útil para distinguir entre tipos en el código.

Por ejemplo, en Java: si comienza con una letra mayúscula, entonces es probablemente una clase. si es ALL_CAPS es probablemente una constante.

Da más versatilidad.


La sensibilidad de mayúsculas es una locura ¿Qué tipo de codificador insano usaría las variables llamadas foo, foO, fOo y fOO, todas en el mismo ámbito? ¡Nunca me convencerás de que haya una razón para la sensibilidad de mayúsculas y minúsculas!


La sensibilidad de mayúsculas y minúsculas no impone estilos de codificación o consistencia. Si pascal case una constante, el compilador no se quejará. Simplemente lo forzará a escribirlo usando una caja pascal cada vez que lo use. Personalmente, me resulta irritante tener que intentar distinguir entre dos elementos que solo difieren en el caso. Es fácil de hacer en un bloque corto de código, pero es muy difícil mantenerlo en un bloque de código muy grande. También tenga en cuenta que la única forma en que las personas pueden usar la distinción de mayúsculas y minúsculas sin volverse locos es si todos siguen rígidamente las mismas convenciones de nomenclatura. Es la convención de nomenclatura que agregó el valor, no la sensibilidad de mayúsculas y minúsculas.


Mantengo un compilador interno para mi empresa, y estoy tentado de hacerlo híbrido: puede usar cualquier caso que desee para un identificador, y debe referirse a él con la misma cubierta, pero nombrando a otra cosa con el mismo nombre y caso diferente causará un error.

Dim abc = 1 Dim y = Abc - 1 '' error, case doesn''t match "abc" Dim ABC = False '' error, can''t redeclare variable "abc"

Actualmente no distingue entre mayúsculas y minúsculas, por lo que probablemente podría solucionar los pocos errores existentes y nadie se quejaría demasiado ...


Me sentí de la misma manera que hace mucho tiempo cuando usaba VB3 / 4 mucho más. Ahora trabajo principalmente en C #. Pero ahora encuentro que los IDE hacen un gran trabajo al encontrar los símbolos y dar buena información sobre los diferentes casos. También me da más flexibilidad en mi propio código ya que puedo tener diferentes significados para los artículos con diferentes casos, lo cual hago mucho ahora.


Muchas personas a las que les gusta la sensibilidad a las mayúsculas y las minúsculas no entienden qué significa "caso en la sensibilidad".

VB .NET no distingue entre mayúsculas y minúsculas. Eso no significa que pueda declarar una variable como abc, y luego referirse a ella como ABC, Abc y aBc. Significa que si lo escribe como cualquiera de esos otros, el IDE lo cambiará automáticamente a la forma correcta.

La insensibilidad a mayúsculas significa que puede escribir

dim a as string

y VS lo cambiará automáticamente a la carcasa correcta

Dim a As String

En la práctica, esto significa que casi nunca tiene que presionar la tecla Shift, ya que puede ingresar todo en minúscula y dejar que el IDE lo corrija.

Pero C # no es tan malo acerca de esto como solía ser. Intellisense en C # es mucho más agresivo de lo que era en VS 2002 y 2003, por lo que el conteo de teclas disminuye bastante.


Para mí, la sensibilidad de mayúsculas y minúsculas es solo un juego en ámbitos como esteValor para un argumento y EsteValor para una propiedad o función pública.

Más que a menudo necesita usar el mismo nombre de variable (ya que representa lo mismo) en diferentes ámbitos y la distinción entre mayúsculas y minúsculas le ayuda a hacerlo sin recurrir a prefijos.

Por lo menos, ya no usamos la notación húngara.


Porque ahora realmente tienes que escribir todo de una manera consistente. Y luego las cosas de repente comienzan a tener sentido.

Si tiene un editor decente, uno que tenga IntelliSense o lo mismo con otro nombre, no debería tener problemas para encontrar nombres que distingan entre mayúsculas y minúsculas.


Porque así es como funciona el lenguaje natural también.


Se siente como una forma más profesional de codificación. No debería necesitar el compilador para averiguar lo que quería decir.


También es un buen hábito si trabaja en Linux y hace referencia a los nombres de los archivos con mayúsculas y minúsculas. Tuve que portar una aplicación Windows ColdFusion para trabajar en Linux y fue una pesadilla total. También algunas bases de datos tienen sensibilidad de mayúsculas activada, imagina la alegría allí.

Sin embargo, es un buen hábito independientemente de la plataforma y sin duda conduce a un estilo de desarrollo más consistente.


Te da más opciones.

Bell bell BEll

son todos diferentes

Además, impulsa a los novatos recién contratados a tratar de descubrir por qué los totales no salen bien; o)))


Una ventaja de VB.NET es que, aunque no distingue entre mayúsculas y minúsculas, el IDE vuelve a formatear automáticamente todo en el caso "oficial" de un identificador que está utilizando, por lo que es fácil ser consistente y fácil de leer.

La desventaja es que odio la sintaxis de estilo VB, y prefiero los operadores estilo C, la puntuación y la sintaxis.

En C #, encuentro que siempre presiono Ctrl-Space para ahorrar tener que usar el tipo correcto.

El hecho de que pueda nombrar cosas que solo difieren según el caso no significa que sea una buena idea, ya que puede llevar a malentendidos si gran parte se filtra a ámbitos más amplios, por lo que le recomiendo que se aparte de ella en la aplicación o subsistema. nivel, pero lo permite solo internamente a una función o método o clase.


Creo que también hay un problema de psicología involucrado aquí. Somos programadores, distinguimos minuciosamente entre cosas. ''a'' no tiene el mismo valor ASCII que ''A'', y me sentiría raro cuando mi compilador los considere iguales. Por eso, cuando escribo

(lista ''a'' b ''c)

en LISP (en REPL), y responde con

(A B C)

mi mente inmediatamente exclama "¡Eso no es lo que dije!". Cuando las cosas no son lo mismo, son diferentes y deben considerarse así ...


Por lo general, paso algo de tiempo con la programación de Delphi en vacaciones, y la mayor parte del tiempo restante solo uso C ++ y MASM. Y una cosa es extraña: cuando estoy en Delphi, no me gusta la sensibilidad de mayúsculas y minúsculas, pero cuando estoy en C ++, lo hago. Me gusta la distinción entre mayúsculas y minúsculas, porque hace que las palabras similares (funciones, variables) se vean similares, y me gusta la sensibilidad sin mayúsculas y minúsculas porque no impone restricciones excesivas a la sintaxis.


De .NET Framework Developer''s Guidebook Convenciones de mayúsculas , mayúsculas y minúsculas:

Las pautas de capitalización existen únicamente para hacer que los identificadores sean más fáciles de leer y reconocer. La carcasa no se puede utilizar como un medio para evitar colisiones de nombres entre los elementos de la biblioteca.

No asuma que todos los lenguajes de programación distinguen entre mayúsculas y minúsculas. Ellos no son. Los nombres no pueden diferir por caso solo.


Después de trabajar muchos años con el código ASP de VBScript heredado, cuando nos movimos a .NET elegimos C #, y una de las principales razones fue la distinción de mayúsculas y minúsculas. El código anterior era ilegible porque las personas no seguían ninguna convención: el código era un desastre ilegible (bueno, los IDEs VBScript pobres ayudaron con eso).

En C # podemos definir convenciones de nomenclatura y todos deben seguirlas. Si algo no está encasillado correctamente, puede cambiarle el nombre (con refactorización, pero esa es una característica IDE) y no habrá ningún problema porque la clase o variable se nombrará de la misma manera en todo el código.

Finalmente, creo que es mucho más legible si todo está correctamente encasillado. Tal vez es más rápido escribir sin distinción entre mayúsculas y minúsculas, pero desde un punto de revisión y mantenimiento de código no es lo mejor porque saltarse el código en busca de algo es más fácil. Por ejemplo, es más fácil encontrar todas las cadenas ''foo'' de un vistazo que buscar ''foo'', ''Foo'', ''FOO'', ''FOo'' ...


Aquí hay muchas respuestas, pero me sorprende que nadie haya señalado el ejemplo obvio que también se burla de un competidor de :

expertSexChange != expertsExchange

El caso es muy importante cuando utiliza nombres de variables de casos de camello.


Los idiomas que no distinguen entre mayúsculas y minúsculas no se generalizan fácilmente a conjuntos de caracteres que no sean ASCII. La conversión adecuada de casos para un idioma que no sea inglés no es una tarea sencilla, y depende de la configuración regional del sistema, entre otras cosas.


La insensibilidad de mayúsculas y minúsculas es muy difícil, a menos que restrinja la sintaxis a ascii (o solo aplique la insensibilidad de mayúsculas y minúsculas a los caracteres ascii), y también debe restringir la configuración regional.

Las reglas para determinar mayúsculas y minúsculas de caracteres no están bien definidas ni son sin pérdida.

Algunos personajes pueden tener más de una forma ''minúscula''. Algunas personas estarán en desacuerdo con respecto a cuál debería ser la forma correcta de mayúscula.

(Algunos idiomas y entornos permiten que casi el carácter se use en los nombres)

Considere En C # ¿cuál es la diferencia entre ToUpper () y ToUpperInvariant ()?