¿Por qué todavía hay mayúsculas y minúsculas en algunos lenguajes de programación?

44

No veo ningún uso de mayúsculas y minúsculas en un lenguaje de programación, aparte de ofuscar código.

¿Por qué implementar esto en un lenguaje de programación?

Actualizar:

Parece que alguien que conoces hizo una declaración sobre esto .

DavRob60
fuente
28
¿Por qué todavía hay insensibilidad a mayúsculas y minúsculas en algunos lenguajes de programación?
Thomas Eding
1
Incluso el inglés distingue entre mayúsculas y minúsculas en general. El ejemplo citado comúnmente es polaco y polaco, que son dos términos diferentes cuyas formas escritas difieren solo en el caso y que tienen diferentes pronunciaciones y significados. En mi opinión, es mejor que la programación no sea demasiado inteligente a este respecto y permita que los programadores mismos presenten convenciones escritas apropiadas. Por ejemplo, es bastante común escribir algo como Person person = new Person()en lenguaje OO donde el símbolo 'persona' es un objeto temporal y 'Persona' es un tipo de clase.
Brandin

Respuestas:

113

Si bien el plegado de mayúsculas y minúsculas es bastante trivial en inglés, lo es mucho menos en otros idiomas. Si un programador alemán usa ßun nombre de variable, ¿qué va a considerar el equivalente en mayúsculas? Solo para tu información, "ß" solo se usa en minúsculas. OTOH, "ss" es equivalente: ¿consideraría que un compilador está obligado a igualarlos? Cuando ingresa a Unicode, obtiene problemas aún más interesantes, como caracteres con signos diacríticos precompuestos versus diacríticos de combinación separados. Luego, llega a algunos scripts en árabe, con tres formas separadas de muchas letras, en lugar de solo dos.

En la era oscura, 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 Control Data, que usaban solo seis bits por carácter (64 códigos, en total). La mayoría de estas máquinas usaban el juego de caracteres "CDC Scientific", que solo contenía mayúsculas. Podí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 se aplicaba a los antiguos códigos Baudot y que se consideraban estándar en los primeros días de COBOL, FORTRAN, BASIC, etc. Para cuando el hardware más capaz estaba ampliamente disponible, su insensibilidad a mayúsculas y minúsculas estaba tan arraigado que era imposible cambiarlo. .

Con el tiempo, la dificultad real de la insensibilidad a mayúsculas y minúsculas se ha hecho más evidente, y los diseñadores de lenguaje han decidido en su mayoría ("realizado" probablemente sería un término más preciso) que cuando / si la gente realmente quiere insensibilidad a mayúsculas y minúsculas, se maneja mejor con herramientas auxiliares que en el lenguaje mismo.

Al menos IMO, el compilador debe tomar la información exactamente como se presenta, no decidir que "usted escribió esto, pero voy a suponer que realmente quiso decir otra cosa". Si desea que se realicen las traducciones, es mejor que las haga por separado, con herramientas creadas para manejarlo bien.

Jerry Coffin
fuente
26
+1, iba a decir algo similar, en mi experiencia, la mayoría de las personas que se quejan de esto son las mismas personas que no consideran otros idiomas / conjuntos de caracteres.
Jeremiah Nunn
55
Mi gran pregunta también, si el compilador va a comenzar a notar diferentes deletreos, ¿debería permitirle poner de manera arbitraria guiones bajos u otros "separadores de palabras"? ¿Intentará "hacer lo que espera" cuando escribe mal un identificador? ¿Hasta dónde llegará? (Por cierto, Ada permite guiones bajos arbitrariamente dentro de los números por razones de claridad.)
dash-tom-bang
3
@Barry: Los dos son más o menos lo mismo: casi todos los demás idiomas del mundo requieren caracteres que no están disponibles en ASCII. Para el caso, a pesar de que de alguna manera nos las arreglamos, en realidad está bastante restringido incluso para el inglés; por ejemplo, te obliga a escribir "cooperación" como "cooperación". Afortunadamente, las máquinas de escribir acostumbraron a las personas a tales restricciones mucho antes de que aparecieran las computadoras, hasta el punto de que pocas personas consideran la posibilidad de usar todos los caracteres que alguna vez se consideraron necesarios.
Jerry Coffin
2
@ dash-tom-bang: se han escrito compiladores que intentaron hacer cosas así (ortografía correcta y otras cosas). La experiencia indica que generalmente es mejor hacer que el compilador se ejecute más rápido y produzca mejores mensajes de error.
Jerry Coffin
2
@phresnel o "SZ". Se pueden hacer buenos argumentos para ambos.
Vatine
114

¿Por qué alguien QUIERE insensibilidad al caso? ¿En qué escenario es útil poder hacer referencia a una sola variable como VARIABLEen un lugar, Variableen otro y variableen un tercero? La insensibilidad a las mayúsculas es exasperante. Prefiero recibir un error del compilador cuando escribo accidentalmente VAriableen Variablelugar de dejar que los errores tipográficos como ese se introduzcan en mi código.

En conclusión, muchos lenguajes de programación tienen sensibilidad a mayúsculas y minúsculas no solo por razones históricas / inerciales sino porque la insensibilidad a mayúsculas es una mala idea.

Sin sombrero
fuente
12
Lo estás mirando de adentro hacia afuera. Sí, referirse a la misma variable con múltiples deletreos puede ser molesto, pero no es tan malo como tener dos identificadores diferentes que se refieren a dos cosas diferentes, en el mismo alcance, que difieren solo en el caso. La insensibilidad de mayúsculas y minúsculas es algo bueno porque evita eso. (Además, evita que un error tipográfico simple se convierta en un error de sintaxis; vea el enlace en la pregunta a la publicación de Jeff sobre el tema.)
Mason Wheeler
88
¡Pero quiero que los errores tipográficos simples sean errores de sintaxis! No quiero errores tipográficos simples en mi código y quiero que mi compilador me ayude a encontrarlos. La insensibilidad de mayúsculas y minúsculas hace que sea más difícil encontrarlos. La insensibilidad a mayúsculas y minúsculas parece una excusa para la codificación descuidada.
nohat
44
@nohat: Estoy de acuerdo, cuando escribe algo diferente a lo que pretendía escribir, un error de sintaxis es algo bueno .
Tim Goodman, el
13
@Mason Wheeler, que han leído el artículo y simplemente no podría estar más en desacuerdo. He usado muchos lenguajes que no distinguen entre mayúsculas y minúsculas y estoy constantemente exasperado por los errores tipográficos.
Nohat
11
Absolutamente de acuerdo con nohat, la insensibilidad a las mayúsculas y minúsculas es una idea ridícula, y por lo general los proponentes provienen de personas que todavía anhelan los buenos días de VB / Basic.
Tim
27

En el caso de Java, la sensibilidad NO se usa para proporcionar más opciones en el código, sino más bien para un significado semántico muy claro y consistente. ClasesLookTikeThis. objectsLookLikeThis. methodLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. NO proporciona una mayor libertad: le permite empaquetar cierta información de manera concisa en lo que es un lenguaje excesivamente detallado.

Creo que en lenguajes explícitamente tipados 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 mayúsculas y minúsculas probablemente causaría aún MÁS resultados inesperados, aunque estaría dispuesto a probar Ruby que no distingue mayúsculas de minúsculas.

Creo que la distinción entre mayúsculas y minúsculas con un sistema estricto no ofusca el código, pero en realidad lo aclara. Considere un posible código Java:

      joe blah = new hUf();

eso está bastante claro, pero ¿qué pasa con:

      hUf.WTF();

En Java tal cual, sabrás automáticamente qué es esto. En Java, que no distingue entre mayúsculas y minúsculas, es ambiguo, por lo que deberá recurrir a algún otro mecanismo para diferenciar las clases de las instancias de los paquetes de los métodos. Y ESE mecanismo probablemente te haría vomitar con lo feo que es :)

Dan Rosenstark
fuente
2
NOOOO! ¡NO MÁS SUBTENSIONES! int package_class_method_var_name? !!
Michael K
2
@ Michael, extraño cómo nadie parece darse cuenta de que el guión bajo es una molestia para escribir.
Dan Rosenstark
2
Depende de tu teclado. Para mí (usando un teclado francés), _ es fácil de escribir, {} son mucho más difíciles (usando AltGr para alcanzarlos).
PhiLho
66
Ah, entonces la sensibilidad a mayúsculas y minúsculas es la nueva notación húngara.
David Thornley
1
Es solo un " significado semántico muy claro y consistente " si el compilador lo aplica. Ahora, un compilador que requirió nombres de clase para comenzar con un carácter en mayúscula y nombres de métodos con minúsculas podría ser una razón interesante para tener mayúsculas y minúsculas.
Ross Patterson el
24

No creo que haya sido "implementado" tanto como "permitido". La distinción entre mayúsculas y minúsculas es el estado predeterminado de las comparaciones de cadenas; el ingeniero del compilador requiere un trabajo adicional para hacer que un idioma no distinga entre mayúsculas y minúsculas, ya que debe agregar un código adicional para realizar comparaciones que no distingan entre mayúsculas y minúsculas y preservar los nombres de tokens originales para los informes correctos de errores y advertencias.

Eso es casi seguro por qué terminó en C; querían crear un lenguaje simple para el que fuera fácil implementar un compilador, a expensas de la usabilidad. ¿Por qué está en idiomas modernos? Como está en C, por supuesto, ¡ debe ser la forma correcta de hacerlo! </ modo sarcasmo>

Mason Wheeler
fuente
3
Además, creo que en los años 60 y 70, cuando se inventaban los lenguajes de programación, el espacio y la velocidad son MUY importantes. No podemos permitirnos esas instrucciones adicionales y espacio para comparaciones que no distinguen entre mayúsculas y minúsculas. Es más un problema de "esa es la forma en que siempre se ha hecho" en los idiomas modernos. No hay razón para que nuevos lenguajes (como C #) hagan esto.
Jay
1
@ Jay: Y, sin embargo, por cualquier razón, Pascal, que precede a C e influyó en su diseño, no distingue entre mayúsculas y minúsculas y aún se compila más rápido. ;)
Mason Wheeler
@Mason: No pensé que Pascal influyera en C ... Tuve que buscarlo. Básicamente, ¡todos vienen de Algol / Fortran! people.mandriva.com/~prigaux/language-study/diagram.png
Jay
1
@ Matt: Umm ... ¿de dónde sacas eso? Todos los recursos que he visto datan de Pascal a 1970 y C a 1972.
Mason Wheeler
16
Los niños de hoy en día. En mi día, no teníamos minúsculas y nos gustó. 6 bits fueron suficientes. Por supuesto, ahora estamos todos sordos por los GRITOS.
KeithB
23

Por lo menos, simplifica el análisis y le permite más combinaciones para nombres de variables / clases.

Con el análisis que no distingue entre mayúsculas y minúsculas, estaría restringido 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 poder determinar qué identificador se utiliza 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 "Write". ¿Lo está llamando en la instancia o en la clase, si no se aplica mayúsculas y minúsculas aquí?

Adam Lear
fuente
14
Sin embargo, esa es una mala convención de nombres. Me gustaría estrangular a alguien si writey Writeeran dos métodos completamente diferentes.
TheLQ
55
Tengo que estar de acuerdo con TheLQ en este caso. Me vuelve loco cuando estoy trabajando en alguna biblioteca de C y veo declaraciones como "HWND hwnd;". Cualquier persona que abusa de la sensibilidad a mayúsculas y minúsculas como esta debería ser sacada y fusilada.
Mason Wheeler
44
@TheLQ los métodos tienen el mismo caso. Estaba usando diferentes casos en los nombres de clase / variable como mi ejemplo.
Adam Lear
66
@ Anne Lear, creo que este es un mal ejemplo. Con un lenguaje que no distinga entre mayúsculas y minúsculas, no tendría que preocuparse por qué método llamar porque ya tendría un error de sintaxis al intentar usar un nombre de clase para un nombre de variable.
Matt Olenik el
55
@Matt no debe codificar sin resaltar la sintaxis. Puedo entender sin un IDE, pero codificar en un editor sin resaltar la sintaxis ... ¿por qué alguien se haría eso a sí mismo?
Davy8
13

Me gusta la distinción entre mayúsculas y minúsculas si no es por otra razón que hace que el código sea más autodocumentado:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Normalmente programo en Python, pero en mis días de C #, me pareció muy conveniente nombrar las instancias de clase de la misma manera que la clase, pero en minúsculas (o camello) (como otros han dicho):

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()

Lo cual 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 entre mayúsculas y minúsculas, esto sería menos fácil. Lo mismo para buscar y reemplazar.

Por último, como programador, cuando veo palabras con diferentes casos, se me ocurre que son cosas diferentes ... Raramente tengo errores en los casos en que los casos variables estaban mal, incluso en lenguajes dinámicos y con guiones en los que un compilador hubiera ayudado.

Hollister
fuente
10

Las personas prestan atención a la forma de las palabras antes de leerlas. La distinción entre mayúsculas y minúsculas 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 abusadas. Los programadores malos siempre generarán código malo ... encontrarán la manera.

Toma el lenguaje como ejemplo. ¿Por qué comenzamos oraciones y nombramos cosas con mayúsculas ... ¿Es también debido a Unix?

Tjaart
fuente
@ SOLO Los comentarios están destinados a buscar aclaraciones, no para una discusión prolongada. Si tiene una solución, deje una respuesta. Si su solución ya está publicada, favor de votarla. Si desea discutir esta respuesta con otras personas, utilice el chat . Consulte las preguntas frecuentes para obtener más información.
Adam Lear
9

Creo que para los idiomas estáticamente tipados como C # y Java, en realidad no agrega ningún valor. Debido a que en la mayoría de los casos, tiene un IDE que de todos modos corregirá automáticamente las discrepancias de casos, por lo que al final del día, si escribo "VAriable" por accidente, mi IDE lo corregirá automáticamente a " Variable "para mí. Agregue a eso las MyClass myClass;convenciones de estilo 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 carcasa consistente no va a agregar mucha más carga.

Entonces sí, aunque no hay una razón real por la que los idiomas no distingan entre mayúsculas y minúsculas, tampoco hay una razón real por la que deberían serlo.

Ese artículo de Scott Hanselman sobre "SignOn" vs "Signon" fue sobre comparaciones de cadenas y nada que ver con lenguajes de programación. Estoy de acuerdo en que las cadenas que escriben los usuarios siempre deben compararse entre mayúsculas y minúsculas, pero creo que es un juego de pelota diferente a los identificadores en un lenguaje de programación.

Dean Harding
fuente
1
+1 por mencionar el "IDE que corregirá automáticamente las discrepancias de mayúsculas y minúsculas"
DavRob60
3
Los IDE son para los débiles. Programa con lápiz y papel, y luego escaneo el código.
Dan Rosenstark
6

Cuando un lenguaje distingue entre mayúsculas y minúsculas, lo 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:

  • En teoría de la probabilidad, la minúscula fgeneralmente representa una función de densidad de probabilidad (pdf), mientras que la mayúscula Frepresenta la función de distribución acumulativa correspondiente (cdf).
  • También en la teoría de probabilidad, las letras mayúsculas denotan variables aleatorias X, y las letras minúsculas correspondientes denotan sus realizaciones x, como en $ Pr [X = x] \ leq 0.05 $.
  • En álgebra lineal, las letras mayúsculas generalmente se usan para referirse a matrices, mientras que las letras minúsculas generalmente se usan para referirse a números, por ejemplo, $ A = [a_ {ij}] $.
  • Los símbolos de las unidades se escriben en letras minúsculas (p. Ej., M para el medidor), excepto el litro (L) y las unidades derivadas del nombre de una persona (W para Watt, Pa para Pascal, N para Newton, etc.).
  • Los símbolos de prefijos que significan un millón o más están en mayúscula (M para mega (millones)), y los de menos de un millón son minúsculas (m para mili (milésimas)).
AN Otro
fuente
3
Punto válido, pero estaría violando las convenciones de codificación de casi todos los lenguajes de programación comunes, que utilizan la distinción entre mayúsculas y minúsculas para sus propios fines ...
Ken Bloom
3

Solo pensé que era por Unix y C, pero eso es un problema de pollo y huevo que solo los malditos pueden responder adecuadamente.

Uso el razonamiento que usaron los pollos en "El conejito de pascua viene a la ciudad" cuando se les preguntó si llegaron antes que los huevos. Como había gallinas en el arca de Noé, las gallinas llegaron primero. Por lo tanto, debido a que GCC se ejecuta en Unix, Unix vino primero, por lo tanto, porque Unix se preocupa mucho por el caso, C y todas sus variantes y descendientes, sí, todo lo que impone llaves, se preocupa por el caso.

Probablemente también haya un vínculo entre llaves y mayúsculas y minúsculas.

Peter Turner
fuente
Unix llegó muchos años antes que GCC, pero el compilador BCPL original vino antes que Unix, y generalmente creó la "sintaxis C".
Ross Patterson el
2

Además de las excelentes respuestas dadas hasta ahora, me gustaría señalar que la distinción entre mayúsculas y minúsculas también le brinda "espacios de nombres" adicionales. Por ejemplo, Perl tiene algunos bloques especiales como BEGINy ENDque se ejecutan en momentos diferentes al código normal (COMENZAR en tiempo de compilación, FINALIZAR después de que el programa normal ha finalizado), y tenerlos como mayúsculas los hace sobresalir, y significa que las minúsculas Las variantes no son palabras reservadas.

Uno puede ir más allá y reservar nombres en mayúsculas para uso futuro por parte del lenguaje, y no hacer ningún daño a los programadores normales, que generalmente NO GRITAN EN SU CÓDIGO.

Moritz
fuente
2

La "distinción entre 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 Unix porque el nombre de archivo en Windows no distingue entre mayúsculas y minúsculas, mientras que el nombre de archivo en Unix distingue entre mayúsculas y minúsculas.

De vuelta a la programación. Para el nombre de clase, nombre de método, nombre de variable, la mayoría de los idiomas no aplican la regla de estilo de nomenclatura. A veces, en aras de la simplicidad, para hacer una "reflexión", simplemente podemos usar el nombre "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.

linquizar
fuente
Disparates. Solo parece reducir la ambigüedad porque ya espera el comportamiento sensible a mayúsculas y minúsculas.
Ross Patterson el
1

Estoy sorprendido por esta diatriba. Ahora que nadie quiere que uses un guión bajo o un m_nombre de campo en C #, acabo de usar el caso de camello, y si el nombre del campo es el mismo que el de una propiedad pública, solo que el nombre de la propiedad pública es el caso de Pascal y creo que el campo de respaldo es el caso de los camellos, "que así sea", eso es lo que parece querer la comunidad de programación en general. No ha causado ningún problema hasta ahora.

Scott Whitlock
fuente
0

Especialmente algunos programadores provienen de los primeros días de BASIC, donde un nombre de variable solo puede tener 2 caracteres.

Y así, cuando puede ser cualquier número de personajes, se vuelven muy felices. Y junto con la distinción entre mayúsculas y minúsculas, porque no quieren preocuparse también por SomeNameser accidentalmente iguales SOMENAMEy causar un error debido a cosas como esta.

Michael W
fuente