¿Por qué a la gente le gusta la sensibilidad a los casos? [cerrado]

https://stackoverflow.com/questions/165455

03-07-2019
|

Pregunta

¿Se pregunta por qué a las personas les gusta la sensibilidad a las mayúsculas en un lenguaje de programación? No estoy tratando de iniciar una guerra de llamas solo por curiosidad eso es todo.
Personalmente, nunca me ha gustado realmente porque encuentro que mi productividad disminuye cuando he probado un lenguaje que distingue mayúsculas y minúsculas. Tenga en cuenta que me estoy calentando / acostumbrándome lentamente ahora que estoy usando C # y F # mucho más que entonces Solía ??hacerlo.

Entonces, ¿por qué te gusta?

Saludos

Solución

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

ALGUNAS PERSONAS QUEDARÍAN ESCRIBIR TODO EN TODAS LAS CAPS, HACIENDO TODO LO MENOS LEGABLE.

La sensibilidad de mayúsculas y minúsculas facilita el uso del " mismo nombre " de diferentes maneras, según una convención de capitalización, por ejemplo,

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

Otros consejos

Una ventaja de VB.NET es que, aunque no distingue entre mayúsculas y minúsculas, el IDE automáticamente formatea todo al formato oficial de " busque el identificador que está utilizando, por lo que es fácil ser consistente, fácil de leer.

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

En C #, encuentro que siempre estoy presionando Ctrl-Space para evitar tener que usar el tipo adecuado.

El hecho de que puedas nombrar cosas que solo difieren según el caso no significa que sea una buena idea, ya que puede dar lugar a malentendidos si gran parte de eso se filtra hacia ámbitos más grandes, por lo que recomiendo evitarlo en la aplicación. o nivel de subsistema, pero permitiéndolo solo internamente a una función, método o clase.

La sensibilidad de mayúsculas y minúsculas no impone estilos de codificación o coherencia. Si tienes una constante constante, el compilador no se quejará. Solo te obligará a escribirlo usando el caso de pascal cada vez que lo uses. Personalmente, me resulta irritante tener que intentar y distinguir entre dos elementos que solo difieren en el caso. Es fácil de hacer en un bloque de código corto, pero muy difícil de mantener recto en un bloque de código muy grande. También tenga en cuenta que la única forma en que las personas pueden realmente usar la sensibilidad a las mayúsculas y minúsculas sin volverse locos es si todas siguen rígidamente las mismas convenciones de nombres. Es la convención de nomenclatura la que agrega el valor, no la sensibilidad al caso.

Mantengo un compilador interno para mi empresa, y estoy tentado de convertirlo en un híbrido. Puede usar el caso que desee para un identificador, y debe referirse a él con la misma carcasa, pero nombrando otra cosa con el el mismo nombre y el caso diferente causarán 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 corregir los pocos errores existentes y nadie se quejaría demasiado ...

Muchas personas a las que les gusta mayúsculas y minúsculas- sensibilidad entienden mal lo que significa el caso- en sensibilidad.

VB .NET no distingue mayúsculas de 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.

Insensibilidad a mayúsculas significa que puede escribir

dim a as string

y VS lo cambiarán automáticamente a la caja correcta

Dim a As String

En la práctica, esto significa que casi nunca tienes que presionar la tecla Mayús, porque puedes escribir en minúsculas y dejar que el IDE sea correcto para ti.

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

Creo que refuerza la coherencia, 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 carcasa hace que el código parezca muy estándar para cualquier programador. Puedes 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 las personas escriban código feo, pero en gran medida las reglas de mayúsculas y puntuación hacen que la escritura sea más fácil de leer, la sensibilidad a las mayúsculas y los estándares de la carcasa hacen que el código sea más fácil de leer.

Creo que es importante que entiendas la diferencia entre lo que es la sensibilidad a los casos y la legibilidad para responder correctamente. Si bien es útil tener diferentes estrategias de revestimiento, puede tenerlas en un idioma que no distinga entre mayúsculas y minúsculas.

Por ejemplo, foo se puede usar para una variable y FOO como una constante tanto en java como en VB. Existe una pequeña diferencia de que VB le permitirá escribir fOo más adelante, pero esto es principalmente una cuestión de legibilidad y es de esperar que se solucione 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 se pone de manifiesto de inmediato lo que es el objeto. Cuando se necesitan varias instancias, obviamente tendrá que elegir una nueva (con suerte nombres significativos), pero en secciones de código pequeñas tiene mucho sentido usar el nombre de la 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 veces de cada 10 vale la pena.

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

expertSexChange != expertsExchange

El caso es muy importante cuando usas nombres de variables de caso de camello.

Te da más opciones.

campana campana TODO

son todos diferentes.

Además, hace que los novatos que fueron contratados se vuelvan locos al tratar de averiguar por qué los totales no están saliendo bien; o)))

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

Si tiene un editor decente, uno que incluya IntelliSense o lo mismo con otro nombre, no debería tener ningún problema para descubrir nombres sensibles a las mayúsculas y minúsculas.

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

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

(lista 'a' b 'c)

en LISP (en el REPL), y responde con

(A B C)

mi mente exclama de inmediato '¡Eso no es lo que dije!'. Cuando las cosas no son iguales, son diferentes y deben considerarse así ...

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

Desde Guía del desarrollador de .NET Framework Convenciones de capitalización , Sensibilidad a mayúsculas y minúsculas:

Las pautas de capitalización existen   únicamente para hacer más fáciles los identificadores   leer y reconocer La carcasa no puede ser   Usado como un medio para evitar el nombre.   Colisiones entre elementos de la biblioteca.

No asumas que toda la programación   Los idiomas distinguen entre mayúsculas y minúsculas. Son   no. Los nombres no pueden diferir por caso   solo.

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

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

Da más versatilidad.

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

Me sentí igual que tú hace mucho tiempo cuando usé VB3 / 4 mucho más. Ahora trabajo principalmente en C #. Pero ahora encuentro que los IDE hacen un gran trabajo para encontrar los símbolos y dar una buena inteligencia en 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, que ahora hago mucho.

También es un buen hábito si trabaja con Linux donde los nombres de archivos de referencia distinguen 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 la sensibilidad a mayúsculas, imagina la alegría allí.

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

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

Puedes aportar un montón de justificaciones de por qué es bueno o malo, pero ninguno de ellos contiene mucha agua. Por ejemplo:

Obtienes más identificadores posibles, por ejemplo. foo vs Foo vs FOO .
Pero tener identificadores que difieran solo en el caso no es una buena idea
Puede codificar información de tipo en un nombre (por ejemplo, FooBar = typename, fooBar = función, foo_bar = variable, FOO_BAR = macro)
Pero puede hacerlo de todos modos con notación húngara

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

En la programación, hay algo que decir sobre la sensibilidad a las mayúsculas y minúsculas, por ejemplo, tener un Foo de propiedad pública y un Foo de campo privado / protegido correspondiente. Con IntelliSense no es muy difícil no cometer errores.

Sin embargo, en un sistema operativo, la sensibilidad a los casos es una locura. Realmente no quiero tener un archivo Foo y foo y fOO en el mismo directorio. Esto me impulsa a cray cada vez que estoy haciendo cosas * nix.

Para mí, la sensibilidad a los casos es solo un juego en ámbitos como esteValor para un argumento y ThisValue para una propiedad o función pública.

Más de las veces, necesita usar el mismo nombre de variable (ya que representa la misma cosa) en diferentes ámbitos y la sensibilidad a mayúsculas y minúsculas lo ayuda a hacer esto sin tener que recurrir a los prefijos.

Menos mal, al menos ya no estamos usando la notación húngara.

Después de trabajar muchos años con el código heredado de VBScript ASP, cuando nos mudamos a .NET elegimos C #, y una de las razones principales fue la sensibilidad a las mayúsculas y minúsculas. El código antiguo era ilegible porque la gente no seguía ninguna convención: el código era un lío ilegible (bueno, los IDE de VBScript pobres ayudaron en eso).

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

Finalmente, creo que es mucho más legible si todo está correctamente colocado. Tal vez es más rápido escribir sin distinción de mayúsculas y minúsculas, pero desde el punto de revisión y mantenimiento del 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' ...

Los lenguajes que no distinguen entre mayúsculas y minúsculas no se generalizan fácilmente a conjuntos de caracteres que no son ASCII. La conversión adecuada de casos para un idioma que no sea el 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 los caracteres no están bien definidas, ni tienen pérdidas.

Algunos caracteres pueden tener más de una forma 'minúscula'. Algunas personas no estarán de acuerdo sobre cuál debería ser la forma correcta en mayúsculas.

(Algunos idiomas y entornos permiten que casi los caracteres se utilicen en los nombres)

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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow