Palabras clave sin distinción entre mayúsculas y minúsculas en un idioma [cerrado]

31

Estamos tratando de escribir un lenguaje de script personalizado. Se ha sugerido que el lenguaje sea indulgente proporcionando palabras clave que no distingan entre mayúsculas y minúsculas .

Personalmente, no me gusta la idea, pero hay pocas personas en mi equipo que se inclinan hacia ella y dicen que hará feliz al usuario final. Se dan ejemplos de lenguajes como FORTRAN, BASIC, SQL que dicen que no distinguen entre mayúsculas y minúsculas.

¿Es esta una buena idea?

Curioso
fuente
44
Bueno, Visual Basic generalmente no distingue entre mayúsculas y minúsculas, ¿eso responde a su pregunta? ; P
yannis
3
Tenga en cuenta que es muy difícil hacer que los identificadores no distingan entre mayúsculas y minúsculas, a menos que limite a los usuarios al conjunto de caracteres ASCII.
Simon Richter
2
@MainMa: C ++ al menos no lo hace directamente. Permite caracteres definido por la implementación en el identificador, pero lo que está garantizada sólo a-zA-Z, 0-9(excepto en el inicio) y _.
Xeo
2
VB6 en realidad utiliza un tipo de enfoque híbrido: puede escribir palabras clave e identificadores de la forma que desee y el IDE los convierte inmediatamente a la forma almacenada. (Incluso puede escribir "endif" y se convertirá en "End If".)
Felix Dombek

Respuestas:

42

Pregúntese quién es el usuario final. Si está destinado a ser escrito por alguien con experiencia en programación en C o Javscript, o experiencia en TI en Unix, entonces la distinción entre mayúsculas y minúsculas es probablemente lo correcto, porque eso es lo que el usuario espera. Pero para la mayoría de los usuarios finales, incluso los usuarios avanzados, esto será confuso.

VB / VBA / VBScript distingue entre mayúsculas y minúsculas, y esta fue una decisión tomada para permitir que los no programadores se familiaricen fácilmente con el lenguaje. Las fórmulas de Excel, no exactamente los scripts, pero lo más cerca que se encuentran muchos usuarios, no distinguen entre mayúsculas y minúsculas. En la mayoría de los casos, la elección del caso puede hacer que el texto se vea más o menos profesional y pulido, pero el caso en sí mismo no cambiará el significado semántico de las palabras. Es por eso que creo que los no desarrolladores se verán confundidos por un lenguaje de script que distingue entre mayúsculas y minúsculas.

Nuevamente, esta no es una opción técnica. Es una elección de gestión de productos que deben hacer las personas que conocen bien al público objetivo.

Avner Shahar-Kashtan
fuente
Piense qué sistemas de archivos distinguen entre mayúsculas y minúsculas antes de mirar los lenguajes de programación. FAT / NTFS para Windows y HFS + para MacOS X no distinguen entre mayúsculas y minúsculas, mientras que UFS / NFS para Unix distinguen entre mayúsculas y minúsculas. A los usuarios avanzados les gusta la capacidad de distinguir archivos / variables por pequeñas diferencias, mientras que la mayoría de los usuarios prefieren mantener las cosas más intuitivas. Como dice Avner, la diferencia es una elección de gestión de productos.
Michael Shopsin
44
Dado que es un lenguaje de secuencias de comandos, es obvio: la insensibilidad a mayúsculas y minúsculas es el camino a seguir. ¿Por qué ser sensible a mayúsculas y minúsculas? Si la respuesta es "ser como C y Java", ¿es realmente una buena razón?
Ben
15
@Ben Python, Ruby, bash, Lua y Perl son ejemplos de lenguajes de script muy populares que distinguen entre mayúsculas y minúsculas. Los idiomas que no distinguen entre mayúsculas y minúsculas incluyen lenguajes empresariales como Delphi y SQL (y COBOL IIRC, si lo cuenta). ¿Por qué es obvio para los lenguajes de scripting y por qué los diseñadores de los lenguajes de scripting más grandes del mundo no están de acuerdo?
2
No puede ser obvio debido a que es un lenguaje de secuencias de comandos: la pregunta relevante es: ¿quién está haciendo las secuencias de comandos y cuál es la mejor opción para ellos? (También me gustaría decir que probablemente debería ser consistente: si sus palabras clave son sensibles a mayúsculas, por favor, no hacen los identificadores entre mayúsculas y minúsculas ...)
comingstorm
@delnan Creo que es una elección lógica que el lenguaje de scripting dirigido al sistema operativo donde se incluye la distinción entre mayúsculas y minúsculas también debería ser sensible a mayúsculas y minúsculas.
Artemix
16

Debe decidir según la experiencia del usuario que desee presentar, no lo fácil o difícil de implementar.

Si facilitará que sus usuarios tengan insensibilidad a mayúsculas y minúsculas, entonces eso es lo que debe implementar.

Como un caso en punto, SQL no distingue entre mayúsculas y minúsculas. Esto hace que sea muy fácil de usar en un entorno interactivo.

Otra forma de ver esto es si alguna vez habrá una diferencia entre keywordy Keyworden su idioma, y ​​¿será esta diferencia significativa para el usuario? Para un lenguaje de secuencias de comandos, diría que la respuesta es "no".

ChrisF
fuente
3
+1 para "¿será significativa esta diferencia para el usuario"? El usuario es lo más importante.
Ben
¿Por qué es SQL más fácil de usar en una configuración interactiva debido a la insensibilidad a mayúsculas y minúsculas? ¿Es porque accidentalmente puede activar el bloqueo de mayúsculas y no darse cuenta?
Kaz
@Kaz: más o menos.
ChrisF
11

Los lenguajes de programación deben ser sensibles a mayúsculas y minúsculas, punto. Las personas pueden adaptarse a esto muy fácilmente: simplemente deben recordar trabajar principalmente en minúsculas y tener cuidado con los identificadores de mayúsculas y minúsculas en las API existentes.

Una vez parecía obvio hacer que los idiomas no distingan entre mayúsculas y minúsculas. Esto se debe a que las minúsculas no estaban disponibles en todos los sistemas informáticos y sus dispositivos de E / S (teclados, impresoras y dispositivos de visualización). Las implementaciones de lenguaje de programación tenían que aceptar programas escritos en mayúsculas, ya que solo eso podía mostrarse o imprimirse. Y para eso tenían que ser mayúsculas y minúsculas, porque aceptar mayúsculas y mayúsculas y minúsculas al mismo tiempo significa rechazar minúsculas. Las minúsculas eran algo que los programadores querían, pero que no siempre podían tener. Nadie realmente quería trabajar con programas que gritaban en mayúsculas; fue solo una limitación de hardware.

Durante un tiempo, era común incluso plegar cajas en los terminales. Si un terminal solo pudiera mostrar mayúsculas, pero tuviera que iniciar sesión en un sistema informático que admita mayúsculas y minúsculas, el terminal plegaría las minúsculas a mayúsculas. ¿Crees que esto fue hace tanto tiempo? "Al igual que el Apple II, el Apple II Plus no tenía funcionalidad en minúsculas". (http://en.wikipedia.org/wiki/Apple_II_Plus) Cuando los usuarios de las primeras computadoras Apple marcaron un BBS que tenía contenido en mayúsculas y minúsculas, el emulador de terminal (o host) tuvo que doblar todo a mayúsculas. Los mensajes escritos en mayúsculas eran comunes en los tableros de anuncios en esos días. Esta funcionalidad todavía se encuentra en sistemas operativos tipo Unix, como el kernel de Linux. Por ejemplo, escriba el stty olcucen su indicador de shell.La disciplina de línea Unix tty puede asignar minúsculas a mayúsculas en la salida, y puede asignar mayúsculas a minúsculas en la entrada. Esto le permite trabajar en un lenguaje de programación en minúsculas, en un terminal que no tiene minúsculas.

La insensibilidad a mayúsculas y minúsculas es un concepto desactualizado de una era informática pasada que no funciona muy bien en el mundo moderno de la informática internacionalizada. ¿Extiende eso a otros idiomas? ¿Qué tal el francés? ¿Consideras que È y è son equivalentes? O japonés? ¿Considera que hiragana y katakana son solo casos, de modo que フ ァ イ ル y ふ ぁ い る son el mismo identificador? El soporte para tal locura complicará enormemente su analizador léxico, que tendrá que tener mapas de equivalencia de casos para todo el espacio Unicode.

Tenga en cuenta que las matemáticas distinguen entre mayúsculas y minúsculas. Por ejemplo, la sigma en mayúscula puede denotar suma, mientras que la sigma en minúscula denota otra cosa, como la desviación estándar. Esto puede ocurrir en la misma fórmula sin crear ninguna dificultad. (¿El lenguaje de programación hará que Σ y σ sean equivalentes?)

La ortografía inglesa es sensible. Por ejemplo, muchos sustantivos propios corresponden a sustantivos ordinarios o incluso a otras partes del discurso. "mayo" es un verbo, pero "mayo" es un mes, o el nombre de una mujer. Además, si se escriben acrónimos o abreviaturas en minúsculas, puede ser confuso. SAT significa prueba de aptitud escolar, mientras que "sat" es el participio pasado de "sentarse". Las personas inteligentes prestan atención a los detalles y capitalizan adecuadamente.

Básicamente, cualquier nuevo lenguaje de programación creado desde 1985 que no distinga entre mayúsculas y minúsculas es PARA AQUELLOS QUE TODAVÍA GRITAN EN CORREOS ELECTRÓNICOS Y PUBLICACIONES SIN UN SEGUNDO PENSAMIENTO.

¿Qué sucede si su idioma alguna vez se usa como un objetivo de generación de código para traducir código en otro idioma y ese otro idioma distingue entre mayúsculas y minúsculas? Tendrá que transformar de alguna manera todos los nombres para capturar la distinción. (Por lo tanto, afirmar que esta no es una decisión técnica, y solo es cuestión de las preferencias emocionales del público objetivo, es ridículo).

Mire los molestos problemas causados ​​por el manejo de casos en Windows, cuando los archivos se importan desde otro sistema operativo. Eso es un problema técnico. Los sistemas de archivos sensibles a mayúsculas y minúsculas tienen un problema con los datos externos que no distinguen entre mayúsculas y minúsculas.

Common Lisp ha dado con el enfoque ideal: los nombres de los símbolos distinguen entre mayúsculas y minúsculas, pero cuando se leen los tokens, se doblan a mayúsculas. Esto significa que las fichas foo, fOO, FOOy Footodos denotan el mismo símbolo: el símbolo cuyo nombre se almacena como la cadena de caracteres "FOO". Además, este comportamiento es solo la configuración predeterminada de la tabla de lectura. El lector puede doblar letras en mayúsculas, minúsculas, invertir las mayúsculas o conservarlas. Las dos últimas opciones dan lugar a un dialecto sensible a mayúsculas y minúsculas. De esta manera, los usuarios tienen la máxima flexibilidad.

Kaz
fuente
1
"¿Qué tal el francés? ¿Consideras que È y è son equivalentes? ¿O japonés? ¿Consideras que hiragana y katakana son solo casos, de modo que フ ァ イ ル y ふ ぁ い る son el mismo identificador?" La respuesta es "sí", y es una locura si crees que las culturas de otras personas son tontas.
Ben
Bueno, prepárate para que explote tu cabecita, porque no creo que las culturas de otras personas sean tontas (con ciertas excepciones, con respecto a los eventos actuales del mundo), pero al mismo tiempo creo que es completamente tonto tratar フ ァ イ ル yふ ぁ い る como el mismo identificador en un lenguaje de programación.
Kaz
@ ¿Conoces las culturas mencionadas? Si supieras de lo que hablaba Kaz, no lo llamarías tonto.
David Cowden
1
@DavidCowden, en ningún momento llamé tonto a Kaz. Estoy de acuerdo en que siempre se debe usar el mismo caso siempre que se use un identificador. La diferencia de Kana es más significativa que la diferencia de mayúsculas y minúsculas, al igual que la diferencia de acento es más significativa que la diferencia de mayúsculas y minúsculas. Sin embargo, así como es tonto tener dos identificadores que difieren solo por caso, también es tonto tener dos identificadores que difieren solo por kana o por acento. Tiene más sentido prohibir los identificadores que difieren solo por kana o acento que tratarlos de la misma manera, pero tiene muy poco sentido tratarlos como diferentes.
Ben
Si prohíbe los identificadores que difieren solo en mayúsculas, minúsculas o kana o lo que sea, entonces está admitiendo tácitamente que son iguales (pero solo insiste en la coherencia). Es mejor no desterrar tales cosas, y dejarlas a los usuarios como una cuestión de codificación de convenciones. Una mejor idea sería tener un sistema declarativo mediante el cual el programa pueda afirmar eso fooy Fooser tratado como sinónimos o como distinto. Sin dicha declaración, es un error que ocurran ambos. Y dado que la declaración no se extiende a FOO, entonces FOOtodavía está prohibido; Tiene que ser añadido.
Kaz
6

El factor determinante real es con qué frecuencia querrás tener varias cosas con el mismo nombre. La insensibilidad a mayúsculas y minúsculas funciona en SQL porque no es frecuente que desee una columna con el nombre SELECT. Sería molesto en Java porque todas las demás líneas se ven Object object = new Object(), donde desea que el mismo nombre haga referencia a una clase, una instancia y un constructor.

En otras palabras, la distinción entre mayúsculas y minúsculas es principalmente útil para sobrecargar un nombre, y la sobrecarga es principalmente útil en proyectos grandes y complejos. Para un uso más infrecuente, como un lenguaje de secuencias de comandos, la insensibilidad a mayúsculas y minúsculas puede hacer que la programación sea mucho más simple.

Una vez hice un lenguaje de reglas donde los identificadores no solo distinguen entre mayúsculas y minúsculas, sino que también insensibilizan los espacios en blanco. También permití crear alias que se referían al mismo identificador. Por ejemplo, ProgrammersStackExchange, los programadores apilan el intercambio y PSE resolvieron exactamente el mismo símbolo y podrían usarse indistintamente.

Para mi dominio, eso funcionó muy bien, porque el dominio tenía muchas formas extremadamente conocidas de referirse a lo mismo, y los conflictos de nombres eran raros. Nadie se sorprendería al escribir una consulta con un nombre y hacer que el resultado use otro. Tener soporte de lenguaje hizo que la traducción entre el dominio y el lenguaje de programación fuera muy fácil. Sin embargo, también dificultaba ciertas tareas, como encontrar todas las referencias a una variable. Afortunadamente, en mi caso ese tipo de situaciones rara vez surgieron, o fueron bastante fáciles de construir herramientas de soporte para ayudar, pero debes tener en cuenta tu propia situación.

Karl Bielefeldt
fuente
No creo que el problema sea querer reutilizar palabras clave para nombres. SQL, Visual Basic y C # (los dos primeros no distinguen entre mayúsculas y minúsculas y el último distinguen entre mayúsculas y minúsculas) resuelven esto permitiendo una forma de citar identificadores: "double quotes"(o [brackets]en MS SQL) en SQL, [brackets]en VB.net y @atsignen C #.
Random832
"con qué frecuencia vas a querer tener varias cosas con el mismo nombre". La insensibilidad entre mayúsculas y minúsculas significa que debe agregar algo de sobrecarga para desambiguar nombres que de otro modo se tratarían por mayúsculas y minúsculas (por ejemplo, m como prefijo para 'miembro' para distinguir de un nombre de propiedad sin prefijo, por ejemplo).
nwahmaet
¿Por qué nombrarías un objeto objeto? Eso es solo pedir problemas.
Ben
@Ben, suponga que está implementando un objeto contenedor, ¿qué más va a llamar el parámetro a su método de agregar?
Winston Ewert
@ WinstonEwert, lo llamaría o. Realmente no importa cómo lo llames, ya que es solo un nombre de parámetro. Siempre que no sea ofensivo o ilegal, o que pueda causar confusión .
Ben
5

Supongamos que su lenguaje de script distingue entre mayúsculas y minúsculas: ¿va a crear un compilador o un verificador de sintaxis que le dirá al usuario si comete un error al usar el caso incorrecto en un nombre de variable o una palabra clave? Si no, ese sería un argumento muy fuerte para hacer que el lenguaje no sea sensible a mayúsculas y minúsculas.

Doc Brown
fuente
Buen punto, pero no una respuesta.
@delnan: tal vez no sea una respuesta tan buena como la de Avner Shahar-Kashtan (a quien le di +1), pero probablemente sea útil para el OP.
Doc Brown
3
Sí, útil como comentario;)
Entonces, si esto se reformula para decir que es solo una buena idea si le advierte al usuario sobre la distinción entre mayúsculas y minúsculas, ¿sería una respuesta? Para mí, eso fue asumido.
JeffO
No, entonces sería un punto menor que difícilmente responde la pregunta formulada como respuesta. EN MI HUMILDE OPINIÓN.
4

¿Puedes declarar variables sobre la marcha? Si es así, argumentaría en contra de mayúsculas y minúsculas, como rastrear un error causado por

ATypo = 42; 

Opuesto a

Atypo = 42; 

está solicitando innecesariamente el tiempo de depuración, cuando tener las dos declaraciones equivalentes simplemente hace la vida más fácil.

NWS
fuente
2
En mi humilde opinión hace que la lectura sea más fácil también. Después de todo, cuando comienzas una oración, escribes en mayúscula la primera palabra, pero no cambias su significado. Lo mismo debería ser para el código!
NWS
2
@delnan: querías legibilidad, usa el mismo alfabeto. ¿Por qué cambiar el significado cuando cambias mayúsculas y minúsculas?
NWS
1
@delnan, según la Corte Suprema de los Estados Unidos de América, los lenguajes de computadora son un lenguaje expresivo diseñado para ser entendido tanto por computadoras como por humanos (cuando se dictamina que el código de computadora está protegido por la primera enmienda). No son inglés, pero son un idioma, y ​​decir "BOB" es diferente de "bob" es diferente de "Bob" es idiota en cualquier idioma destinado a ser utilizado por humanos. Sí, podemos aprender a lidiar con eso, pero eso no es excusa alguna.
Ben
2
@Ben Déjame hacer una analogía. La notación matemática es, a diferencia de los lenguajes de programación, exclusiva para humanos. El argumento habitual de que la insensibilidad a mayúsculas y minúsculas es un artefacto histórico de las computadoras antiguas no se aplica aquí. Sin embargo, dudo que cualquier matemático argumentaría eso ay Adebería ser intercambiable. Presentan casos consistentemente, sin excepciones. Por ejemplo, en algunos contextos, las letras mayúsculas se usan para conjuntos, mientras que las letras minúsculas son miembros del conjunto. Otro ejemplo ocurre en la ingeniería eléctrica, las minúsculas dependen del tiempo y las mayúsculas son independientes del tiempo ...
2
@Ben ... en estos y otros contextos, no veo la distinción entre mayúsculas y minúsculas como una restricción. Lo veo como liberar símbolos redundantes para ser utilizados de una manera más productiva, a través de convenciones que comunican significado aunque, entre otros medios, la capitalización. Al igual que cualquier notación específica de dominio, esto puede parecer ajeno al lego pero permite a los expertos comunicarse mejor y más rápidamente.
2

Se dan ejemplos de lenguajes como FORTRAN, BASIC, SQL que dicen que no distinguen entre mayúsculas y minúsculas.

La razón por la que FORTRAN y SQL (y COBOL) no distinguen entre mayúsculas y minúsculas es que fueron diseñados originalmente para su uso en máquinas donde los juegos de caracteres normales solo tenían letras mayúsculas. La insensibilidad de mayúsculas y minúsculas en esos idiomas (al menos) es más un artefacto histórico que una elección de diseño de lenguaje.

Ahora podría argumentar que la insensibilidad a mayúsculas y minúsculas es más indulgente, pero la otra cara es que la sensibilidad a mayúsculas y minúsculas da como resultado un código más legible porque FOCALIZA EL CODIFICADOR PARA UTILIZAR LA CAPACIDAD DE CONFIGURACIÓN.

Stephen C
fuente
44
Estoy harto del argumento "X es bueno, Y hace cumplir Z relacionado, por lo tanto, Y hace bien haciendo cumplir X" (por ejemplo, estilo de codificación sensata / Python / regla de fuera de juego). Ningún buen programador capitaliza de una manera que afecte seriamente la legibilidad, incluso cuando se lo permite. Aquellos que abusan de la insensibilidad a mayúsculas y minúsculas también capitalizan de manera inconsistente en un entorno sensible a mayúsculas y minúsculas (y cometen otras cien atrocidades), simplemente se ven obligados a usar la misma mala capitalización para cada uso de un nombre individual. Los malos programadores pueden escribir Fortran en cualquier idioma. (Descargo de responsabilidad: ¡soy un gran admirador de mayúsculas y minúsculas!)
Adivina qué. Estoy harto de tener que leer el código escrito por programadores malos que piensan que son tan buenos programadores que pueden desarrollar sus propias reglas de estilo únicas. (Descargo de responsabilidad: aprendí a programar en los días de FORTRAN y COBOL, y detesto la insensibilidad a los casos y otras atrocidades lingüísticas de esa época.)
Stephen C
Cualquier uso de mayúsculas en un lenguaje insensible a mayúsculas constituye abuso de insensibilidad.
Kaz
@Kaz - erm ... intenta decirle eso a un millón de programadores de SQL.
Stephen C
1

La sensibilidad a mayúsculas y minúsculas se considera dañina.

La vida no distingue entre mayúsculas y minúsculas y tampoco lo son los usuarios o programadores.

Los lenguajes sensibles a mayúsculas y minúsculas son un accidente histórico, de sistemas restringidos que encontraron difíciles las comparaciones entre mayúsculas y minúsculas. Esta desventaja ya no existe, por lo que no hay razón para volver a crear un sistema informático que distinga entre mayúsculas y minúsculas.

Diría que la sensibilidad a mayúsculas y minúsculas es mala , ya que antepone la conveniencia de la computadora a la del usuario.

(Relacionado, recuerdo hace unos años, un genio se negó a pagar la factura de su tarjeta de crédito porque su nombre estaba en mayúsculas, pero lo deletreó en mayúsculas y minúsculas. Por lo tanto, argumentó, no estaba dirigido adecuadamente a él y no estaba una demanda válida de pago. El juez trató el argumento como se merecía).

Ben
fuente
La distinción entre mayúsculas y minúsculas no antepone la conveniencia de la computadora a la del usuario. He implementado lenguajes que distinguen entre mayúsculas y minúsculas, y la única diferencia es una llamada de función adicional en algunos lugares. Además, otras respuestas dicen que el caso en -sensibilidad es un artefacto histórico debido a los conjuntos de caracteres limitados, lo que contradice su teoría, ¿no?
Unicode pone esto en un reino completamente diferente.
DeadMG
3
Ese blog no da ninguna justificación de por qué es malo en C, solo en Python o PHP, y el OP no habla de identificadores sensibles a mayúsculas y minúsculas, solo palabras clave . Ese enlace no tiene absolutamente nada que decir sobre ese tema.
DeadMG
1
@Ben Editors puede (y lo hace) arreglar la carcasa mientras escribe, independientemente de las reglas del idioma. Permitir errores que, sin embargo, se deslizan (por ejemplo, porque no tiene un editor sofisticado a la mano) no ayuda. Significa dejar un problema, en lugar de quejarse para solucionarlo. Además, una vez que uso mayúsculas consistentes, puedo tener múltiples identificadores diferentes en cada caso, pero que denotan cosas muy diferentes y que son fáciles de analizar para los humanos gracias al contexto y la capitalización, sin ambigüedad.
2
@Ben: en algunos idiomas, hay costumbres lexográficas muy estrictas, o incluso reglas. En C y C ++, todo en mayúsculas es una macro, y las macros deben seguir siendo todo en mayúsculas para evitar confusiones. Algunos idiomas tienen diferentes significados para los símbolos con o sin mayúsculas iniciales (y no sé qué tan bien lo harían en varios idiomas que no tienen las letras mayúsculas y minúsculas correspondientes). Si tiene reglas o convenciones como esa, obtiene algo del efecto de diferentes espacios de nombres, y la duplicación de nombres de identificadores en diferentes espacios de nombres a menudo funciona.
David Thornley
1

Desde mi experiencia personal, no veo una gran diferencia entre los idiomas sensibles a mayúsculas y minúsculas.

Lo más importante es la nomenclatura y las convenciones estructurales que un programador debe mantener en su código y ningún compilador o analizador lo comprueba por él. Si te apegas a algún tipo de reglas, sabrás fácilmente un nombre propio (no pensarás si nombraste una variable checkOut o CheckOut) y tu código probablemente distinga entre mayúsculas y minúsculas y sea más fácil de leer.

No se debe usar CheckOut y checkOut y checkout y cHeCkOuT y CHECKOUT en el mismo significado. Hará daño a la lectura y hará que la comprensión de ese tipo de código sea más dolorosa (pero hay algo peor que uno puede hacer para destruir la lectura del código).

Si usa algún tipo de reglas, verá a simple vista, por ejemplo:

CheckOut.getInstance () - es un método estático de una clase llamada checkOut.calculate () - es un método de un objeto guardado en un campo variable o público llamado _checkOut.calculate () - es un método de un objeto guardado en un campo privado llamado CHECKOUT - es un campo / variable estático o constante final

sin consultar otros archivos o partes de un archivo. Hace que la lectura del código sea más rápida.

Veo que muchos desarrolladores usan reglas similares, en lenguajes que uso a menudo: Java, PHP, Action Script, JavaScript, C ++.

En un caso raro, uno puede estar enojado por la insensibilidad a las mayúsculas y minúsculas, por ejemplo, cuando desea usar CheckOut para un nombre de clase y checkOut para una variable y no puede porque choca entre sí. Pero es un problema de un programador que se usa para distinguir entre mayúsculas y minúsculas y para usarlo en sus convenciones de nomenclatura. Uno puede tener reglas con prefijos o postfijos estándar en un lenguaje que no distinga entre mayúsculas y minúsculas (no programo en VB pero sé que muchos programadores de VB tienen este tipo de convenciones de nomenclatura).

En pocas palabras: veo una mejor distinción entre mayúsculas y minúsculas (solo para lenguajes orientados a objetos) porque la mayoría de los desarrolladores usan lenguajes sensibles a mayúsculas y minúsculas y usan convenciones de nomenclatura basadas en mayúsculas y minúsculas, por lo que les gustaría que un lenguaje sea más sensible a mayúsculas y minúsculas para que sean capaz de cumplir con sus reglas sin algún tipo de modificaciones. Pero es un argumento bastante religioso, no uno objetivo (no basado en inconvenientes reales o buenos aspectos de la distinción entre mayúsculas y minúsculas), porque no veo ninguno cuando se trata de un buen desarrollador, cuando se trata de un DEVeLoPeR bAD se podría producir un código de pesadilla incluso cuando hay mayúsculas y minúsculas, por lo que no es una gran diferencia).

Zbyszek
fuente
1

Los lenguajes de programación deben ser insensibles a mayúsculas y minúsculas.

La razón principal por la que muchos idiomas en estos días distinguen entre mayúsculas y minúsculas es simplemente el diseño de lenguaje de culto de carga: "C lo hizo de esa manera, y C es increíblemente popular, por lo que debe ser correcto". Y como en tantas otras cosas, C se equivocó demostrablemente.

Esto es en realidad parte de la filosofía de conducción detrás de C y UNIX: si tiene que elegir entre una mala solución que es fácil de implementar y una buena solución que es más difícil de implementar, elija la mala solución y empuje la carga de trabajar en su desorden el usuario. Esto puede sonar como snark, pero es absolutamente cierto. Es conocido como el "principio de lo peor es mejor", y ha sido directamente responsable de daños por valor de miles de millones de dólares en las últimas décadas debido a C y C ++, lo que hace que sea demasiado fácil escribir software con fallas e inseguridad.

Hacer que un lenguaje no sea sensible a mayúsculas y minúsculas es definitivamente más fácil; no necesita las tablas lexer, parser y symbol para tener que hacer el trabajo extra de asegurarse de que todo coincida de una manera que no distinga entre mayúsculas y minúsculas. Pero también es una mala idea, por dos razones:

  • Primero, especialmente si está construyendo un lenguaje de script, un error tipográfico simple en el que llama a algo "myObject" en un lugar y "MyObject" en otro, donde obviamente se refiere al mismo objeto pero es un poco inconsistente con las mayúsculas , no se convierte en un error de tiempo de ejecución. (Esto es infame como un punto de dolor importante en los lenguajes de secuencias de comandos que se equivocan, como Python).
  • Segundo, no tener mayúsculas y minúsculas significa que no se puede abusar de mayúsculas y minúsculas para que la misma palabra se refiera a dos cosas diferentes en el mismo alcance simplemente cambiando la capitalización. Si alguna vez tuvo que trabajar con el código de Windows en un entorno C y se encontró con declaraciones feas HWND hwnd;, sabrá exactamente de lo que estoy hablando. Las personas que escriben así deberían ser eliminadas y fusiladas, y hacer que el lenguaje no distinga entre mayúsculas y minúsculas evita que el abuso de mayúsculas y minúsculas llegue a su código.

Por lo tanto, haga un esfuerzo adicional para hacerlo bien. El código resultante será más limpio, más fácil de leer, tendrá menos errores y hará que sus usuarios sean más productivos, ¿y ese no es el objetivo final de ningún lenguaje de programación?

Mason Wheeler
fuente
Los lenguajes de programación deben tener un alcance léxico para detectar este tipo de error antes del tiempo de ejecución (incluso si de otro modo son altamente dinámicos). Common Lisp es un lenguaje altamente dinámico, sin embargo, los compiladores nos dicen cuándo usamos una variable que no tiene enlace léxico y no se definió globalmente como una variable dinámica. No puede confiar en la insensibilidad de mayúsculas y minúsculas para esto porque desea detectar todos los errores tipográficos, no solo los que involucran mayúsculas y minúsculas.
Kaz
No me importa HWND hwnd;. Este es un ejemplo donde la sensibilidad a mayúsculas y minúsculas funciona bien. Sin embargo, la convención de "Indian Hill" en mayúsculas es una tontería. hwnd_t hwndes mucho mejor. Sospecho que todo se debe a FILE. Hubo un tiempo en la versión 6 de Unix tenía en su archivo de E / S cabecera biblioteca de esto: #define FILE struct _iobuf. Estaba en mayúsculas porque era una macro. Cuando se convirtió en typedef en ANSI C, se mantuvo la ortografía de mayúsculas. Y creo que es por imitación de esto que la convención ALL_CAPS_TYPE fue inventada y codificada en la "Guía de estilo Indian Hill" de Bell Lab. (¡La original!)
Kaz
Si ahora busca en Google "Indian Hill Style Guide", encontrará principalmente referencias a un documento de 1990 de Bell Labs que se arrepiente por completo de los nombres de mayúsculas y minúsculas: no hay rastros de ninguna de esas recomendaciones. Pero la versión original recomendaba cosas como typedef struct node *NODE. Estoy seguro de que es donde Microsoft debe haber recogido esto. Entonces, culpe a Bell Labs por HWND.
Kaz
1

No puedo creer que alguien haya dicho "la distinción entre mayúsculas y minúsculas facilita la lectura del código".

¡Ciertamente no! He mirado por encima del hombro de un colega las variables llamadas Compañía y compañía (compañía de variable pública, compañía de variable privada emparejada) y su elección de fuente y color hace que sea increíblemente difícil distinguir entre las dos, incluso una al lado de la otra.

La declaración correcta debe ser "mayúsculas y minúsculas facilita la lectura del código" Esa es una verdad mucho más obvia, por ejemplo, variables llamadas CompanyName y CompanyAddress en lugar de companyname. Pero ningún lenguaje que conozca te hace usar solo nombres de variables en minúsculas.

La convención más loca que conozco es la "mayúscula pública, minúscula privada". ¡Solo está pidiendo problemas!

Mi opinión sobre los errores es "mejor que algo falle ruidosamente y lo antes posible en lugar de fallar silenciosamente pero parece tener éxito". Y no hay antes que el tiempo de compilación.

Si por error usa una variable en minúsculas cuando pretendía usar mayúsculas, a menudo se compilará si hace referencia a ella dentro de la misma clase . Por lo tanto, puede parecer que tiene éxito tanto en el tiempo de compilación como en el de ejecución, pero está haciendo sutilmente lo incorrecto y quizás no lo detecte durante mucho tiempo. Cuando detectas que hay algo mal

Es mucho mejor usar una convención donde la variable privada tiene un sufijo, por ejemplo, la variable pública de la compañía, la variable privada de la compañía. Nadie va a mezclar accidentalmente los dos, y aparecen juntos en el intellisense.

Esto contrasta con una objeción que las personas tienen a la notación húngara, donde una variable privada prefijada pCompany no aparecería en un buen lugar en el intellisesne.

Esta convención tiene todas las ventajas de la terrible convención de mayúsculas / minúsculas y ninguno de sus inconvenientes.

El hecho de que las personas sientan la necesidad de recurrir a la sensibilidad a las mayúsculas y minúsculas para distinguir entre variables muestra tanto la falta de imaginación como la falta de sentido común, en mi opinión. O, lamentablemente, a la oveja humana le gusta la costumbre de seguir una convención porque "esa es la forma en que siempre se ha hecho"

¡Haz que las cosas con las que trabajas sean claras y obviamente diferentes entre sí, incluso si están relacionadas!

Andy R
fuente
1
De acuerdo, entonces companyName == companyname. Eso parece razonable, pero ¿cómo manejas las configuraciones regionales? ¿Compilar su programa en diferentes partes del mundo causará semántica diferente, como lo hace en PHP? ¿Serás completamente anglocéntrico y solo admitirás el conjunto imprimible ASCII en identificadores? La insensibilidad a mayúsculas y minúsculas es una gran complejidad adicional para obtener muy poca ganancia adicional.
Phoshi
0

No debe introducir insensibilidad a mayúsculas y minúsculas sin una muy buena razón para hacerlo. Por ejemplo, lidiar con las comparaciones de casos con Unicode puede ser una perra. La distinción entre mayúsculas y minúsculas (o la falta de ella) de los idiomas más antiguos no tiene importancia, ya que sus necesidades eran muy diferentes.

Los programadores en esta era esperan mayúsculas y minúsculas.

DeadMG
fuente
1
Las comparaciones de casos no son tan difíciles. Simplemente descomponga sus identificadores. É = E '= e' = é. Recuerde, aún puede elegir qué reglas de caso seguir, y el inglés es una opción razonable. (ciertamente si sus palabras clave también están en inglés)
MSalters
2
Sí, son "tan difíciles", en todo el espacio Unicode.
Kaz
1
¿"Los programadores en esta era esperan mayúsculas y minúsculas"? Solo si tienen el Síndrome de Estocolmo por haber trabajado con la familia C durante demasiado tiempo.
Mason Wheeler
Bueno, la familia C solo representa, como, una gran proporción de lenguajes y códigos. Además, creo que es algo bueno y su comentario no propone ninguna razón por la cual no lo es.
DeadMG
0

La distinción entre mayúsculas y minúsculas hace que el código sea más legible y la programación más fácil.

  • Las personas encuentran que el uso apropiado de mayúsculas y minúsculas es más fácil de leer .

  • Permite / alienta a CamelCase de modo que la misma palabra con un caso diferente pueda referirse a cosas relacionadas: por lo Car car; tanto, la variable nombrada carse crea de tipo Car.

  • ALL_CAPS_WITH_UNDERSCORES indica constantes por convención en muchos idiomas

  • all_lower_with_underscores se puede usar para variables miembro u otra cosa.

  • Todas las herramientas de programación modernas (control de fuente, editores, diff, grep, etc.) están diseñadas para distinguir entre mayúsculas y minúsculas. Siempre tendrá problemas con las herramientas que los programadores dan por sentado si crea un lenguaje que no distinga entre mayúsculas y minúsculas.

  • Si se interpretará el idioma, puede haber una penalización de rendimiento para el análisis del código que no distingue entre mayúsculas y minúsculas.

  • ¿Qué pasa con los caracteres no ingleses? ¿Decide ahora no admitir nunca el copto, el chino y el hindi? Le sugiero encarecidamente que haga que su idioma predetermine todo para UTF-8 y que sea compatible con algunos idiomas que tienen caracteres sin mayúsculas o minúsculas. No utilizará estos caracteres en sus palabras clave, pero cuando comience a desactivar la distinción entre mayúsculas y minúsculas en varias herramientas (para encontrar cosas en los archivos, por ejemplo), se encontrará con algunas experiencias surrealistas y probablemente desagradables.

Cual es el beneficio? Los 3 idiomas que menciona son de los años 70 o anteriores. Ningún lenguaje moderno hace esto.

Por otro lado, cualquier cosa que realmente haga feliz al usuario final trae un poco de luz al mundo. Si realmente afectará la felicidad del usuario, entonces tienes que hacerlo.

Si desea que sea realmente simple para los usuarios finales, puede hacerlo mejor que la sensibilidad / insensibilidad a las mayúsculas y minúsculas: ¡eche un vistazo a Scratch ! Unos pocos gatos de dibujos animados y colores más amigables para los negocios, y tienes el lenguaje más amigable que he visto, ¡y no tienes que escribir nada! Solo un pensamiento.

GlenPeterson
fuente
1
Creo que querías decir "la insensibilidad a las mayúsculas y minúsculas es una pesadilla". Los japoneses tienen casos: hiragana y katakana son, más o menos, casos diferentes. Al igual que A y a son "iguales" de cierta manera, también lo son あ y ア. Katakana a veces se usa para enfatizar, de manera similar en mayúsculas en idiomas que usan el alfabeto romano. No hace falta decir que sería una idiotez tratar a hiragana y katakana como iguales en los identificadores de lenguaje de programación.
Kaz
Gracias, ¡eso es enriquecedor! Limpié mi publicación solo un poco.
GlenPeterson
1
Car car;es uno de los mejores argumentos en contra de la distinción entre mayúsculas y minúsculas: es feo, y si su lenguaje no distingue entre mayúsculas y minúsculas, no puede abusar de las mayúsculas y minúsculas de esa manera.
Mason Wheeler
1
Es Car myCar;mucho mejor?
GlenPeterson
@Mason Wheeler: Si limitamos nuestras construcciones de lenguaje a aquellas de las que no podemos abusar, no podremos hacer mucho, ¿verdad? Mi consejo para cualquiera que esté abusando de mayúsculas y minúsculas es "No".
David Thornley