¿Por qué muchos idiomas sensible a mayúsculas y minúsculas?

https://stackoverflow.com/questions/503218

20-08-2019
|

Pregunta

Es simplemente una cuestión de herencia?C++ es sensible a mayúsculas porque C, Java es sensible a mayúsculas, debido a que C++ es, etc.?O es que hay un más pragmático de la razón detrás de ella?

Solución

Unix.

Unix distingue entre mayúsculas y minúsculas, y muchos lenguajes de programación desarrollados para su uso en Unix distinguen entre mayúsculas y minúsculas.

Las computadoras no son indulgentes: un carácter en mayúscula no es lo mismo que un carácter en minúscula, son completamente diferentes. Y cuando se procesaban los ciclos, la memoria RAM y demás eran caros, no se consideraba que valiera la pena el esfuerzo para obligar a los compiladores y las computadoras a ser & "; Indulgentes &"; La gente solo intentaba que las cosas funcionaran .

Observe cómo la insensibilidad a mayúsculas y minúsculas realmente no se convirtió en algo útil hasta que llegaron cosas como Visual Basic - una vez que las empresas comenzaron a invertir en el concepto de que hacer que las masas programaran era algo bueno para sus resultados (es decir, Microsoft gana más dinero si hay más programas en Windows), los idiomas comenzaron a ser más amigables y más indulgentes.

Otros consejos

No creo que obtenga una mejor respuesta que & "; porque los autores de ese idioma pensaron que era mejor así &"; Personalmente, creo que tienen razón. Odiaría encontrar estas líneas en cualquier lugar del mismo archivo fuente (y referirme al mismo objeto + método) ...

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

No creo que a nadie le guste ver esto ...

Una cosa interesante a considerar es que el inglés también distingue entre mayúsculas y minúsculas. (Sospecho que esto es cierto para la mayoría de los idiomas naturales, pero puede no ser cierto para todos).

Hay una gran diferencia (donde vivo, de todos modos, cerca de la ciudad de Reading) entre:

Me gusta leer.

Del mismo modo, aunque muchas personas lo hacen escriben en mayúsculas de forma incorrecta, y generalmente puede entender lo que significa, eso no significa que dicha escritura se considere correcta . Soy un fanático cuando se trata de este tipo de cosas, lo que no quiere decir que yo mismo haga todo bien, por supuesto. No sé si eso es parte de la herencia de la mayúsculas y minúsculas del lenguaje de programación, pero sospecho que puede ser.

Una ventaja distintiva de la distinción entre mayúsculas y minúsculas para los lenguajes de programación es que el texto también se vuelve culturalmente insensible. Ya es bastante malo tener que deletrear ocasionalmente a un compilador qué codificación de texto se usa para un archivo fuente; tener que especificar en qué cultura se encuentra sería aún peor :(

En realidad es extremadamente práctico, tanto para el desarrollador como para la especificación de la sintaxis del lenguaje: la distinción entre mayúsculas y minúsculas agrega una gran expresividad a los nombres de identificadores.

Desde el punto de vista de la sintaxis del lenguaje, puede forzar que ciertos identificadores comiencen con minúsculas o mayúsculas (por ejemplo, el nombre de la clase Java). Eso facilita el análisis y, por lo tanto, ayuda a mantener limpia la sintaxis.

Desde el punto de vista del desarrollador, esto permite una gran cantidad de convenciones de codificación convenientes, haciendo que su código sea más claro y fácil de entender.

Supongo que la mayúscula aumenta el espacio de nombres. Un buen truco como

MyClass myClass;

sería imposible con el compilador sin distinción entre mayúsculas y minúsculas.

El plegado de mayúsculas y minúsculas solo es simple en inglés (y para todos los caracteres < 128). El alemán sz o & Quot; sharp s & Quot; (& # 223;) no tiene una variante en mayúsculas en el juego de caracteres ISO 8859-1. Solo recibió uno en Unicode después de una década de discusión (y ahora, todas las fuentes deben actualizarse ...). Kanji e Hiragana (alfabetos japoneses) ni siquiera saben en minúsculas.

Para evitar este desorden, incluso en esta era de Unicode, no es aconsejable permitir el plegado de mayúsculas y minúsculas de los identificadores y unicode.

Cuando el análisis y la compilación eran muy costosos y llevaban toda la noche, era ventajoso para el compilador si no tenía que preocuparse por el caso.

Una vez que surgieron los identificadores que solo eran únicos a través de su caso, se volvió muy difícil regresar. A muchos desarrolladores les gustó y no parece haber un gran deseo de deshacerlo.

ExpertSexChange

Creo que este es un competidor de Stack Overflow donde tienes que pagar para leer las respuestas. Hmm ... con insensibilidad a mayúsculas y minúsculas, el significado del nombre del sitio es ambiguo.

Esta es una buena razón para que los idiomas distingan entre mayúsculas y minúsculas. ¡Menos ambigüedad! La ambigüedad para los programadores se considera asquerosa.

La distinción entre mayúsculas y minúsculas aumenta la legibilidad del lenguaje mediante el uso de convenciones de nomenclatura. No puedes escribir

Person person = new Person("Bill");

si su idioma no distingue entre mayúsculas y minúsculas, porque el compilador no podría distinguir entre el nombre de la Clase y el nombre de la variable.

Además, tener a Persona, persona, PersoN, PeRsOn y PERSON, todos son tokens equivalentes, me daría dolor de cabeza. :)

¿Cuál es la forma capital de i ? I (U + 0049) o & # 304; (U + 0130)?

Las mayúsculas dependen de la configuración regional.

Muchos idiomas (que no son de programación) (por ejemplo, el europeo que usa el alfabeto romano) distinguen entre mayúsculas y minúsculas, por lo que es natural que los hablantes nativos de esos idiomas utilicen distinciones en mayúsculas / minúsculas.

La idea misma de que los lenguajes de programación no distinguen entre mayúsculas y minúsculas es un artefacto histórico que surge de las limitaciones del hardware de generación anterior (incluidas las máquinas de teletipo previas a la computadora que usaban un carácter de 5 bits) código).

Las personas que abogan por lenguas ciegas deben ser incapaces de distinguir

IAmNowHere

IAmNowhere

( ¡Es una broma! ;-)

Porque son tan tontos como una caja de ranas , precisamente por las razones dadas para el punto de vista opuesto en este hilo (ni siquiera voy a preguntar de qué se trata. Madera para los árboles y todo eso).

Cuando FOOBAR = FooBar = foobar, puedes elegir tu convención, y otros codificadores pueden hacer lo mismo si comparten tu preferencia o no . Sin confusión.

Tampoco pueden salirse con el golpe de genio que tiene una constante, función y variable, todas con el mismo nombre en el mismo archivo, aunque con mayúsculas diferentes. De nuevo, no hay confusión.

¿Llamas a tu sitio web variable, ellos llaman a su sitio web y qué sistema se confunde? Tampoco es una captura fácil cuando escanea.

En cuanto a las búsquedas, ¿es realmente mucho más procesamiento convertir el nombre a minúsculas antes de buscarlo? Hacer su propia optimización prematura es una cosa, esperar que el desarrollador de su idioma de elección sea un nivel completamente diferente de perder el punto.

... y, sin embargo, todas estas respuestas dicen que la distinción entre mayúsculas y minúsculas reduce la confusión. Sigh

También hay Common Lisp, que es un lenguaje sensible a mayúsculas y minúsculas que muchas personas creen erróneamente que no distingue entre mayúsculas y minúsculas. Cuando escribe (car x) en el Listener, se convierte en (CAR X) para el procesamiento. Es posible definir símbolos con nombres en minúscula, pero se deben citar con algo como |lower-case-symbol|. Por lo tanto, escribir (Car X) o <=> o <=> funciona igual.

(Franz Lisp estaba en un punto introduciendo lo que llamaron " moderno " mayúsculas, en el que el oyente no doblaba los casos, y las palabras clave CL estarían en minúsculas. Nunca lo seguí lo suficientemente bien para saber qué pasó allí).

Mayúsculas de una letra no es un concepto universal . Java usa Unicode, por lo que si desea Java sin distinción entre mayúsculas y minúsculas, el significado de su programa podría cambiar dependiendo de la configuración regional en la que se compiló.

La mayoría de los idiomas no le permiten poner puntos o comas (o apóstrofes o espacios) en el medio de los literales enteros, probablemente porque eso también depende de la configuración regional.

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

Existen las pautas de capitalización   únicamente para hacer que los identificadores sean más fáciles de   leer y reconocer La carcasa no puede ser   utilizado como un medio para evitar el nombre   colisiones entre elementos de la biblioteca.

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

¿Cómo gritas si no tienes GORRAS? AHHH!

Tienes que ser expresivo. Pero con toda honestidad, de todas las personas en el mundo, aquellos que trabajan con lógica de programación serían los primeros en insistir en que las diferencias son en realidad diferencias.

La sensibilidad a mayúsculas y minúsculas realmente no ayuda a la consistencia de mayúsculas y minúsculas.

Foo.Bar  
foo.Bar  
fOO.bAR

En un lenguaje insensible a las mayúsculas y minúsculas que el editor puede corregir automáticamente. En un caso sensible al lenguaje, solucionarlo es más difícil, ya que puede ser legal. El editor primero debe verificar si existen foo.Bar y fOO.bAR y también tiene que adivinar que escribió con el caso incorrecto en lugar de olvidarse de declarar la variable (ya que Foo es diferente a fOO).

Mucha gente aquí ha dicho que sería malo que varias formas de capitalización se refieran a lo mismo, por ejemplo:

person
perSoN
PERSON

Lo que sería realmente malo es si todos estos se refieren a diferentes objetos en el código. Si tiene variables persona, perSoN y PERSON, todas referidas a cosas diferentes, tiene un problema.

Todos los ejemplos que he visto que distinguen entre mayúsculas y minúsculas se basan en el deseo de escribir código incorrecto y no descriptivo. p.ej. la " fecha " vs. " myDate " argumento: estos son igualmente poco descriptivos y malas prácticas. Una buena práctica es nombrarlo como realmente es: fecha de nacimiento, fecha de contratación, fecha de factura, lo que sea. ¿Y quién en su sano juicio querría escribir código como:

Public Class Person
    Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
    Public person As Person = person.PERSON
End Class

Sorprendentemente, este es un caso perfectamente válido en código VB.Net sensible. La idea de que la sensibilidad a mayúsculas y minúsculas le permite desobedecer aún más las buenas prácticas de programación es un argumento en contra, no a favor.

Debido a que muchas personas encuentran a employeeSocailSecurityNumber tan legible como employee_social_security_number y es más corto.

Creo que tener un lenguaje que distinga entre mayúsculas y minúsculas ALIENTA a las personas a escribir código pobre.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize)
{
   int ShoeSIZE = 10
   return ShoeSize
}

Duh. No se le ocurre un nombre de variable mejor que & Quot; ShoeSize & Quot; para los diferentes propósitos? Hay mil millones de palabras diferentes que podrías usar, pero ¿eliges seguir usando ShoeSize?

Y también podría (tontamente) usar letras simples (" a " y " b " y " c " ;) para todas las clases, variables, funciones y métodos.

Pero ¿POR QUÉ quieres?

Use nombres que tengan sentido , no:

function a(a)
{
    int a = a.a;
    return a
}

Hay otra razón por la cual los idiomas distinguen entre mayúsculas y minúsculas. Los ID pueden almacenarse en una tabla hash y las tablas hash dependen de las funciones hash que proporcionarán diferentes hash para diferentes casos. Y puede que no sea conveniente convertir todas las ID a todas las superiores o todas las inferiores antes de ejecutarlas a través de la función hash. Me encontré con este problema cuando estaba escribiendo mi propio compilador. Fue mucho más simple (más vago) declarar mi idioma como sensible a mayúsculas y minúsculas.

He leído todo este hilo. Debo creer que aquellos que informan haber encontrado valor en mayúsculas y minúsculas nunca han programado en un lenguaje de alto nivel verdadero (que por definición no distingue entre mayúsculas y minúsculas). K & Amp; R admite que C es de nivel medio. Después de programar en Pascal, Delphi, Lazarus, ADA, etc., uno aprende que el código altamente legible es fácil de escribir y de ejecutar rápidamente sin obsesionarse con las construcciones sensibles a mayúsculas y minúsculas. Después de todo, legibilidad es la primera y la última palabra sobre el tema. El código está escrito para el humano, no para la computadora. No hay problemas para depurar con código que no distingue mayúsculas de minúsculas. Cuando se baja a un lenguaje de nivel medio, se encuentra que NO hay ventajas para la mayúsculas y minúsculas. Sin embargo, un número considerable de horas dedicadas a la depuración de mayúsculas y minúsculas causó problemas. Especialmente cuando se juntan módulos de diferentes codificadores. También parece que un gran número de encuestados no entiende lo que se entiende por insensibilidad a mayúsculas y minúsculas. Solo se ven afectados los caracteres a-z. Estos son un subconjunto secuencial de caracteres ASCII. Tres o cuatro bytes de código de máquina hacen que el compilador sea indiferente al caso en este rango de caracteres. No altera la barra inferior, los números ni nada más. Los puntos sobre otros idiomas y conjuntos de caracteres simplemente no se aplican a esta discusión. El compilador o el interruptor se codificarían para convertir temporalmente o no convertir el carácter para el análisis en tiempo de compilación basado en ser ASCII o no.

Estoy sorprendido por los nuevos lenguajes como Python que han salido repitiendo el error que cometió K & amp; R. Sí, guardaron media docena de bytes en un entorno donde la RAM total para el compilador, el código fuente y el código objeto fue de 1000 bytes. Eso fue entonces. Ahora la memoria no es un problema. Ahora, sin ninguna razón sensata, ¡incluso las palabras de reserva en Python distinguen entre mayúsculas y minúsculas! No creo que deba usar & Quot; Para & Quot; de " Imprimir " como variable o nombre de función. Pero esa posibilidad ha sido preservada por el costoso tiempo dedicado a contentarse con el interruptor sobre el caso exacto de cada identificador. Un mal trato, creo.

Lo más cercano que he leído hasta la fecha en apoyo de mayúsculas y minúsculas son los comentarios sobre Hashing. Pero estos eventos de codificación raros que se pueden manejar con cuidadosa atención al detalle no parecen valer la pena el escrutinio inútil que un codificador debe usar para escribir código sensible a mayúsculas y minúsculas. Dos puntos de vista del problema. Uno fomenta la codificación incorrecta, establece trampas en el código y requiere atención adicional para desviarlo de conceptos más grandes. El otro no tiene inconvenientes, ha funcionado a la perfección en lenguajes de alto nivel y permite flexibilidad si no hace daño. Me parece que otro caso de VHS gana a BETA. Solo valen mis dos centavos aquí.

El aprendizaje siempre es más fácil por ejemplo, así que aquí va:

C#(sensible a mayúsculas y minúsculas, pero se puede usar desde VB.NET que es insensible a mayúsculas-minúsculas):

CONSTANT_NAME
IInterfaceName // Uses I prefix in all case sensitive and insensitive languages
ClassName      // Readable in both case sensitive and insensitive languages
_classMember   // sometimes m_classMember or just classMember
DoSomething(someParam) // Method with action name, params can be _someParam
PropertyName   // Same style in case sensitive and insensitive languages
localVariable  // Never using prefix

Java y JS usar un estilo similar a la de C# pero los métodos/funciones/eventos se declaran como variables de haceralgo, onEvent.

ObjectPascal(Delphi y Lázaro/FPC son sensibles a mayúsculas y minúsculas, como ADA y VB.NET)

CConstantName     // One can use Def or no prefix, not a standard
IInterfaceName
TClassName        // Non-atomic types/classes have T prefix e.g. TStructRecordName
PSomePointer      // Pointers have types, safer low level stuff
FClassFieldMember // F means Field member similar to m
DoSomething(Parameter) // Older code uses prefix A for parameters instead
PropertyName
LLocalVariable    // Older code uses prefix for parameters not local vars

Utilizando sólo OneCase y prefijos para cada tipo tiene sentido en todos los idiomas.Incluso los idiomas que se inició sin prefijos tienen nuevas construcciones como las Interfaces que no dependen de caso, pero el uso de un prefijo en su lugar.

Así que realmente no es importante, si una lengua es sensible a mayúsculas y minúsculas o no.Los conceptos más nuevos se han añadido a mayúsculas y minúsculas idiomas que eran demasiado confusos para ser expresada por caso solo y requiere el uso de un prefijo.

Desde el caso sensibles idiomas se inició el uso de prefijos, es razonable dejar de usar con el mismo nombre de identificador someIdentifier SomeIdentifier SOME_IDENTIFIER, ISomeIdentifier y sólo utilizar los prefijos donde tiene sentido.

Considerar este problema:Usted tiene un miembro de la clase que se llama algo, un método/función del parámetro que se llama algo y una variable local que se llama algo, ¿qué caso convención podría ser utilizada para diferenciar fácilmente entre estos ?¿No es más fácil usar la mayoría de los ConsistentCaseStyle en todas partes y agregar un prefijo ?

Los Fans de mayúsculas y minúsculas idiomas de atención acerca de la calidad del código, solo quieren un estilo.A veces aceptan el hecho de que una biblioteca está mal escrito y el uso de un estilo estricto, mientras que la biblioteca puede tener ningún estilo o pobres código.

Tanto sensible a mayúsculas y minúsculas idiomas que requieren una estricta disciplina, tiene más sentido tener un solo estilo por todas partes.Sería mejor si tuviéramos un lenguaje que se utiliza sólo StrictCase, un estilo en todas partes y prefijos.

Hay un montón de buenos código C, caso de la sensibilidad no hacerlo legible y no se puede hacer nada al respecto.En un caso insensible lenguaje podría cumplir un buen estilo en el código sin tener que reescribir la biblioteca.En un StrictCase un lenguaje que no existe aún, todo el código que habría de calidad decente :)

Parece que la mayoría de la gente está de acuerdo en que la distinción entre mayúsculas y minúsculas es importante y yo estoy de acuerdo.

Sin embargo, puede ser molesto cuando tiene que escribir algo en el caso correcto, por lo que creo que el IDE debería permitirle escribir en el caso incorrecto, pero si presiona el acceso directo de autocompletar, debería hacer una coincidencia entre mayúsculas y minúsculas. Esto nos da lo mejor de ambos mundos.

Según los estándares de codificación típicos, Person sería una clase, person un nombre de variable y PERSON una constante. A menudo es útil usar la misma palabra con diferentes mayúsculas para referirse a algo relacionado pero ligeramente diferente.

Entonces, si tuvieras tres miembros del personal en tu negocio todos llamados Robert, te referirías a ellos como Robert, Robert y ROBERT, ¿verdad? ¿Y confiar en que la gente sepa exactamente a qué te refieres?

¿Darles direcciones de correo electrónico como Robert@widgets.com, robert@widgets.com y ROBERT@widgets.com si su sistema de correo electrónico distingue entre mayúsculas y minúsculas?

El potencial de una violación no autorizada de datos personales sería enorme. Sin mencionar si envió la contraseña raíz de la base de datos al empleado descontento a punto de ser despedido.

Es mejor llamarlos Bob, Robbie y Robert. Mejor aún llamarlos Robert A, Robert B y Robert C si sus apellidos fueran p. Arthur, Banks y Clarke

Realmente, ¿por qué en el mundo hay una convención de nomenclatura que invita a errores o confusión, que depende de que las personas estén muy alertas? ¿Te faltan palabras en tu vocabulario?

Y en cuanto a la persona que menciona el truco supuestamente útil " MyClass myClass " - ¿Por qué, por qué? Deliberadamente, hace difícil ver de un vistazo si un método utilizado es un método de clase o un método de instancia.

Además, perdió la oportunidad de decirle a la próxima persona que lea su código más sobre la instancia particular de la clase.

Por ejemplo.

Cliente Anterior Cliente

Cliente nuevo cliente

Cliente CorporateCustomer

¡Su nombre de instancia necesita idealmente decirle a su colega más que solo la clase en la que se basa!

Si la separación de palabras no es importante, ¿por qué ponemos espacios entre las palabras? Por lo tanto, creo que los subrayados entre palabras en un nombre aumentan la legibilidad. También la letra minúscula con mayúsculas de los caracteres apropiados es más fácil de leer. Por último, seguramente es mucho más fácil si todas las palabras pueden transmitirse de boca en boca: & "; Cliente de subrayado corporativo &"; en lugar de & "; mayúscula C mayúscula o p o r a t Subrayar mayúscula mayúscula C u s t o m e r &" ;! - el primero se puede hablar 'en la cabeza' el segundo no puede - Me pregunto cómo las personas que están contentas con mayúsculas y minúsculas manejan estos nombres sensibles a mayúsculas y minúsculas en sus cerebros - Realmente lucho. Así que creo que la distinción entre mayúsculas y minúsculas no es de ninguna ayuda: en mi opinión, un paso retrogade de COBOL.

Porque la gente en serio overthink cosas.

Caso de insensibilidad funciona mejor cuando también sensibles a las mayúsculas y combinado con una separación entre el tipo de variable y espacios de nombres.Esto significa que:

Si usted declarar una clase como 'TextureImage'y, a continuación, pruebe a utilizar como"textureImage', el IDE puede autocorrección usted.Esto le da la ventaja de que usted nunca tendrá que golpear la tecla de mayúsculas a menos que usted está declarando un identificador o el uso de un carácter de subrayado.
Al igual que en Java y otros lenguajes;es perfectamente válido, escriba "MyClass myClass".El IDE y el compilador no debe tener ningún problema para diferenciar entre el uso de un tipo y el uso de una variable.

Además, en caso de insensibilidad garantiza que 'o'y 'O"nunca se refieren a los diferentes objetos.Argumentos comunes incluyen:

"sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => y que alguien le _never_ se les permite unirse a un equipo de programación, por lo que este es un strawman argumento.incluso si se las arregló para hacerlo, caso de que la insensibilidad es más la solución que del problema, porque significa que usted no tiene que recordar lo loco mayúsculas/minúsculas combinación que uso.
"no se puede internacionalizar el caso de insensibilidad fácilmente!";=> más del 95% de los lenguajes de programación están escritos en inglés por una muy buena razón.no hay competencia codificaciones de caracteres y la gran mayoría de los teclados en la tierra son en ingles (parcial o totalmente).el apoyo de unicode identificadores es quizás la más tonta idea de que alguien ha entrado en el siglo 21;debido a que una buena parte de los caracteres unicode son frikkin invisible surragates, código de lectura es bastante difícil sin tener que usar el traductor de google, y la escritura de código es bastante difícil sin tener que copiar y pegar los identificadores o el uso de un mapa de caracteres.
"pero sensible a mayúsculas y minúsculas idiomas tienen más identificadores!";=> no, ellos tienen gramaticalmente sobrecargado identificadores, que es sustancialmente peor.

Yo no uso mayúsculas y minúsculas idiomas, pero las ventajas son claramente de manifiesto si usted piensa acerca de este tipo de cosas en serio.

Una respuesta razonable podría ser que los diseñadores del lenguaje lo pensaron haría el lenguaje más fácil de entender pensando en el futuro :)

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

No afiliado a StackOverflow