No veo ningún uso para la distinción entre mayúsculas y minúsculas en un lenguaje de programación, aparte de ofuscar el código.
¿Por qué implementar esto en un lenguaje de programación?
Actualizar:
Parece que alguien que usted conoce hizo una declaración al respecto .
Si bien el plegado de casos es bastante trivial en inglés, mucho menos en otros idiomas.
Si un programador alemán usa ß en un nombre de variable, ¿qué va a considerar el equivalente en mayúsculas? Solo para su información, "ß" es solo alguna vez usado en minúsculas. OTOH, "ss" es equivalente, ¿consideraría a un compilador obligado a encontrarlos? Cuando te metes en Unicode, obtienes problemas aún más interesantes, como los personajes con signos diacríticos precompuestos frente a los diacríticos combinados separados. Luego llega a algunos scripts en árabe, con tres formas separadas de muchas letras, en lugar de solo dos.
En la Edad Media, la mayoría de los lenguajes de programación no distinguen entre mayúsculas y minúsculas, casi por necesidad. Por ejemplo, Pascal comenzó en los mainframes de datos de control, que utilizaban solo seis bits por carácter (64 códigos, total). La mayoría de estas máquinas utilizaban el conjunto de caracteres "CDC Scientific", que solo contenía mayúsculas. Podría cambiar a otros conjuntos de caracteres, pero la mayoría tenía mayúsculas o minúsculas, pero no ambas, pero usaba los mismos códigos para ambas. Lo mismo sucedió con los antiguos códigos de Baudot y el estándar considerado en los primeros días de COBOL, FORTRAN, BASIC, etc. En la época en que se disponía de un hardware más capaz, no se distinguía tanto entre mayúsculas y minúsculas que era imposible cambiarlo. .
A lo largo del tiempo, la verdadera dificultad de la falta de sensibilidad a los casos se ha hecho más evidente, y los diseñadores del lenguaje han decidido ("se dio cuenta" que probablemente sería un término más preciso) que cuando / si la gente realmente quiere la insensibilidad a los casos, es mejor manejarla. por herramientas auxiliares que en el propio lenguaje.
Al menos en la OMI, el compilador debería tomar la entrada exactamente como se presentó, no decidir que "usted escribió esto, pero voy a asumir que realmente quiso decir otra cosa". Si desea que las traducciones se realicen, es mejor que las haga por separado, con herramientas diseñadas para manejarlas bien.
¿Por qué alguien querría insensibilidad a los casos? ¿En qué escenario es útil poder referirse a una sola variable como VARIABLE en un lugar, Variable en otro y variable en un tercero? La insensibilidad a los casos es exasperante. Preferiría obtener un error de compilación cuando accidentalmente escribo VAriable en lugar de Variable en lugar de dejar que se tipifiquen mayúsculas y minúsculas como esa en mi código.
En conclusión, muchos lenguajes de programación tienen sensibilidad a las mayúsculas y minúsculas no solo por razones históricas / de inercia, sino porque la insensibilidad a las mayúsculas y minúsculas es una mala idea.
En el caso de Java, la sensibilidad NO se usa para proporcionar más opciones en el código, sino para un significado semántico muy claro y consistente. ClassesLookLikeThis. objetosLookLikeThis. methodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. NO proporciona mayor libertad: le permite incluir cierta información de manera concisa en lo que es un lenguaje demasiado detallado.
Creo que en lenguajes explícitamente tipificados estáticamente con mucho compilador y soporte IDE, la distinción entre mayúsculas y minúsculas es una excelente manera de comunicar información (por ejemplo, Java). Con lenguajes como Ruby, la insensibilidad a los casos probablemente causaría incluso MÁS resultados inesperados, aunque estaría abierto a probar Ruby que no distingue entre mayúsculas y minúsculas.
Creo que la sensibilidad a las mayúsculas y minúsculas con un sistema estricto no confunde el código, pero en realidad lo hace más claro. Considere el posible código de Java:
joe blah = new hUf();
eso está bastante claro, pero ¿qué pasa con:
hUf.WTF();
En Java como está, usted sabría automáticamente qué es esto. En Java, que no distingue entre mayúsculas y minúsculas, es ambiguo, por lo que tendrías que recurrir a algún otro mecanismo para diferenciar las clases de las instancias de los paquetes de los métodos. Y ESE mecanismo te haría vomitar con lo feo que es :)
No creo que se haya "implementado" tanto como "permitido". La sensibilidad de mayúsculas y minúsculas es el estado predeterminado de las comparaciones de cadenas; se requiere trabajo adicional para que el ingeniero del compilador haga que un idioma no distinga entre mayúsculas y minúsculas, ya que necesita agregar un código adicional para realizar comparaciones entre mayúsculas y minúsculas y preservar los nombres de token originales para el informe de errores y advertencias correcto.
Eso es casi seguro por qué terminó en C; querían hacer un lenguaje simple para el que fuera fácil implementar un compilador, a expensas de la facilidad de uso. ¿En cuanto a por qué está en langauges modernos? Porque está en C, por supuesto, ¡así que debe ser la manera correcta de hacerlo! < / sarcasm mode >
Si no es otra cosa, simplifica el análisis y le permite más combinaciones para nombres de variables / clases.
Con un análisis que no distingue entre mayúsculas y minúsculas, estaría limitado a tener que usar identificadores únicos, ya que 'myClass' y 'MyClass' serían lo mismo. Alternativamente, tendría que agregar capas de complejidad a su analizador para asegurarse de que podría determinar qué identificador se usa según el contexto.
Considere un caso como este:
XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");
Supongamos que la clase XmlWriter también tiene un método estático llamado "Escribir". ¿Lo está llamando en la instancia o en la clase, si no se aplica la distinción entre mayúsculas y minúsculas aquí?
Me gusta la distinción entre mayúsculas y minúsculas si, por ninguna otra razón, hace que el código se autodocumente:
this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename
Por lo general, programo en Python, pero en mis días de C #, me pareció muy conveniente nombrar las instancias de clase igual que la clase, pero en el caso inferior (o en camello) (como han dicho otros):
Thing thing = new Thing();
El uso de lenguajes que no distinguen entre mayúsculas y minúsculas requiere alguna otra convención para esto, es decir, algún tipo de sigilo como:
Thing oThing = new Thing()
Thing instanceOfThing = new Thing()
Que es una "cosa mala".
También me parece conveniente grep (distingue entre mayúsculas y minúsculas) para encontrar referencias a una clase frente a los usos de una variable. Con un lenguaje que no distinga mayúsculas y minúsculas, esto sería menos fácil. Lo mismo para búsqueda y amp; reemplazar.
Por último, como programador, cuando veo palabras con diferentes casos, me parece que son cosas diferentes ... Raramente tengo errores cuando los casos de variables eran incorrectos, incluso en lenguajes de script dinámicos donde un compilador lo haría han ayudado.
La gente presta atención a la forma de las palabras antes de leerlas. La sensibilidad de la caja mantiene la forma de un símbolo consistente en todo el código. También estoy de acuerdo con los anteriores que afirman que las diferentes convenciones denotan diferentes tipos de símbolos. La sensibilidad a los casos y la insensibilidad pueden ser objeto de abuso. Los malos programadores siempre generarán un código malo ... encontrarán un camino.
Tomemos el lenguaje como ejemplo. ¿Por qué empezamos oraciones y nombramos cosas con mayúsculas ... También se debe a Unix?
Creo que para los lenguajes de tipo estático como C # y Java, en realidad no agrega ningún valor. Porque en la mayoría de los casos, tienes un IDE que corregirá automáticamente los desajustes de casos de todos modos, por lo que al final del día, si escribo "VAriable" por accidente, mi IDE lo corregirá automáticamente para " Variable "para mí. Agregue a eso las convenciones de estilo MyClass myClass; y podrá ver que la distinción entre mayúsculas y minúsculas no es necesariamente algo malo.
Para los idiomas de tipo dinámico, puede haber más argumentos, ya que es más difícil para un IDE adivinar una autocorrección, pero en el caso de los idiomas de tipo dinámico, ya tiene mucho más de qué preocuparse ( en términos de errores tipográficos) que el uso de una convención de carcasas consistente no va a agregar mucha más carga.
Así que sí, aunque no hay ninguna razón real por la que no sea sensible a mayúsculas y minúsculas, tampoco existe una razón real por la que debería tampoco.
El artículo de Scott Hanselman sobre "SignOn" vs "Signon" fue sobre comparaciones de cadenas, y nada que ver con los lenguajes de programación. Estoy de acuerdo en que las cadenas que escriben los usuarios siempre deben compararse con mayúsculas y minúsculas, pero creo que es un juego de pelota diferente a los identificadores en un lenguaje de programación.
Cuando un idioma distingue entre mayúsculas y minúsculas, aprovecho para reproducir el uso de casos convencionales en matemáticas y ciencias. Aquí hay una lista (de ninguna manera exhaustiva) de algunas convenciones de casos:
f generalmente representa una función de densidad de probabilidad (pdf), mientras que mayúscula F representa la función de distribución acumulativa correspondiente (cdf).
X , y las letras minúsculas correspondientes denotan sus realizaciones x , como en $ Pr [X = x] \ leq 0.05 $.
Me di cuenta de que era debido a Unix y C, pero eso es una especie de problema con la gallina y el huevo que solo los geezers pueden responder correctamente.
Utilizo la justificación que los pollos en "El conejito de Pascua está viniendo a la ciudad" usaron cuando se les preguntó si estaban antes que los huevos. Porque había pollos en el Arca de Noé, los pollos eran los primeros. Por lo tanto, debido a que GCC se ejecuta en Unix, Unix fue el primero, por lo tanto, debido a que Unix se preocupa tanto por el caso, C y todas sus variantes y descendientes, y todo lo que impone llaves, cuida el caso.
Probablemente también hay un vínculo entre llaves y sensibilidad a las mayúsculas.
Además de las excelentes respuestas dadas hasta ahora, me gustaría señalar que la sensibilidad al caso también le brinda "espacios de nombres" adicionales. Por ejemplo, Perl tiene algunos bloques especiales como BEGIN y END que se ejecutan en momentos diferentes al código normal (COMENZAR en tiempo de compilación, FIN después de que el programa normal haya finalizado), y tenerlos como mayúsculas los hace sobresalir, y significa que las variantes en minúscula no son palabras reservadas.
Uno puede ir aún más lejos y reservar los nombres en mayúsculas para el futuro uso del lenguaje, y no hacer ningún daño a los programadores normales, que normalmente NO GRITAN EN SU CÓDIGO.
"Las mayúsculas y minúsculas" siempre es mejor para las personas técnicas para reducir la ambigüedad. Tome el nombre de archivo como ejemplo. Tratar con el nombre de archivo de Windows es más problemático que el nombre de archivo de Unix porque el nombre de archivo en Windows no distingue entre mayúsculas y minúsculas, mientras que el nombre de archivo en Unix lo es.
Volver a la programación. Para el nombre de la clase, el nombre del método, el nombre de la variable, la mayoría de los idiomas no aplican la regla de estilo de denominación. A veces, para simplificar la "reflexión", simplemente podemos usar el nombre de "mayúsculas y minúsculas" para enlazar a otra fuente de datos sin conversión, o manejar el problema del mismo nombre pero en un caso diferente.
Estoy sorprendido por esta perorata. Ahora que nadie quiere que uses un guión bajo o un m_ en un nombre de campo en C #, acabo de usar el caso de camello, y si el nombre de campo es el mismo que el nombre de una propiedad pública, solo el nombre de la propiedad pública Es el caso de Pascal y el campo de respaldo es el caso de los camellos, me imagino que "así sea", eso es lo que la comunidad de programación en general parece querer. No ha causado ningún problema hasta ahora.
Especialmente algunos programadores provienen de los primeros días de BASIC, donde un nombre de variable solo puede tener 2 caracteres de longitud.
Y así, cuando puede haber cualquier número de personajes, se vuelven muy felices. Y junto con la sensibilidad a las mayúsculas y minúsculas, ya que no quieren preocuparse porque SomeName sea accidentalmente igual a SOMENAME y cause un error debido a cosas como esta.
Lea otras preguntas en las etiquetas programming-languages syntax