design - segun - ventajas de hablar varios idiomas
¿Por qué son muchos idiomas sensibles a las may (30)
MyClass myClass; sería imposible con el compilador insensible a mayúsculas y minúsculas.
O puede ser inteligente y usar 2 palabras diferentes ... que muestren mejor lo que realmente está tratando de hacer, como:
MyClass myCarDesign;
Duh.
¿Por qué son muchos idiomas sensibles a las may
¿Es simplemente una cuestión de herencia? C ++ distingue entre mayúsculas y minúsculas porque C es, Java distingue entre mayúsculas y minúsculas porque C ++ es, etc. ¿O hay una razón más pragmática detrás de esto?
Según los estándares de codificación típicos, Person sería una clase, una persona con un nombre de variable y PERSON una constante. A menudo es útil utilizar la misma palabra con mayúsculas diferentes para significar 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, ¿o sí? ¿Y confía en la gente para saber exactamente a qué te refieres?
Déles direcciones de correo electrónico como [email protected], [email protected] y [email protected] 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 de la raíz de la base de datos al empleado descontento a punto de ser despedido.
Mejor llamarlos Bob, Robbie y Robert. Mejor aún llamarlos Robert A, Robert B y Robert C si sus apellidos fueran, por ejemplo, Arthur, Banks y Clarke
Realmente, ¿por qué en la tierra tienen una convención de nomenclatura que invita a cometer errores o confusión, que depende de que la gente esté muy alerta? ¿Estás tan corto de palabras en tu volcabulary?
And as for the person who mentions the supposedly handy trick "MyClass myClass" - why, why why? You deliberately make it difficult to see at a glance whether a method used is a class method or an instance method.
Plus you lost the chance to tell the next person reading your code more about the particular instance of the class.
For instance.
Customer PreviousCustomer
Customer NewCustomer
Customer CorporateCustomer
Your instance name needs to ideally tell your colleague more than just the class it''s based on!
¿Cómo gritas si no tienes TAPONES? AHHH!
Tienes que ser expresivo. Pero honestamente, 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, de hecho, diferencias.
¿Cuál es la forma capital de i ? I (U + 0049) o İ (U + 0130)?
La capitalización depende de la configuración regional.
Aprender es siempre más fácil con el ejemplo así que aquí va:
C # (distingue entre mayúsculas y minúsculas pero utilizable de VB.NET que no distingue entre mayúsculas y 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 usan un estilo similar a C # pero los métodos / funciones / eventos se declaran como variables doSomething, onEvent.
ObjectPascal (Delphi y Lazarus / FPC no distinguen entre 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
Usar solo OneCase y prefijos para cada tipo tiene sentido en todos los idiomas. Incluso los lenguajes que comenzaron sin prefijos tienen construcciones más nuevas, como las interfaces que no dependen del caso sino que usan un prefijo.
Entonces, realmente no es importante si un idioma es sensible a mayúsculas o no. Se agregaron conceptos más nuevos a los idiomas sensibles a mayúsculas y minúsculas que eran demasiado confusos para ser expresados solo por el caso y requerían el uso de un prefijo.
Dado que los idiomas sensibles a mayúsculas y minúsculas comenzaron a usar prefijos, es razonable dejar de usar mayúsculas y minúsculas con el mismo nombre de identificador someIdentifier SomeIdentifier SOME_IDENTIFIER, ISomeIdentifier y simplemente usar prefijos donde tenga sentido.
Considere este problema: tiene un miembro de la clase llamado algo, un método / parámetro de función llamado algo y una variable local llamada algo, ¿qué convención de caso podría usarse para diferenciar fácilmente entre estos? ¿No es más fácil simplemente usar el estilo más consistente en todas partes y agregar un prefijo?
Los fanáticos de los idiomas insensibles a las mayúsculas y minúsculas se preocupan por la calidad del código, solo quieren un estilo. Algunas veces aceptan el hecho de que una biblioteca está mal escrita y usan un estilo estricto mientras que la biblioteca puede no tener estilo o código pobre.
Tanto los lenguajes sensibles a las mayúsculas como las insensibles requieren una disciplina estricta, tiene más sentido tener un solo estilo en todas partes. Sería mejor si tuviéramos un lenguaje que usara solo StrictCase, un estilo en todas partes y prefijos.
Hay un montón de código C pobre, la distinción entre mayúsculas y minúsculas no lo hace legible y no puede hacer nada al respecto. En un lenguaje que no distingue entre mayúsculas y minúsculas, puede imponer un buen estilo en su código sin reescribir la biblioteca. En un lenguaje StrictCase que aún no existe, todo el código tendría una calidad decente :)
Creo que la sensibilidad de mayúsculas amplía el espacio de nombres. Un buen truco como
MyClass myClass;
sería imposible con el compilador insensible a mayúsculas y minúsculas.
Creo que tener un lenguaje sensible a mayú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 podría pensar en un nombre de variable mejor que "ShoeSize" para los diferentes propósitos? Hay mil millones de palabras diferentes que podrías usar, ¿pero eliges simplemente seguir usando ShoeSize?
De .NET Framework Developer''s Guidebook Convenciones de mayúsculas , mayúsculas y minúsculas:
Las pautas de capitalización existen únicamente para hacer que los identificadores sean más fáciles de leer y reconocer. La carcasa no se puede utilizar como un medio para evitar colisiones de nombres entre los elementos de la biblioteca.
No asuma que todos los lenguajes de programación distinguen entre mayúsculas y minúsculas. Ellos no son. Los nombres no pueden diferir por caso solo.
Debido a que muchas personas consideran que employeeSocailSecurityNumber es tan legible como employee_social_security_number y es más corto.
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 "sharp s" (ß) no tiene una variante en mayúscula en el juego de caracteres ISO 8859-1. Solo recibió uno en Unicode después de aproximadamente una década de discusión (y ahora, todas las fuentes deben actualizarse ...). Kanji e Hiragana (alfabeto japonés) ni siquiera saben minúsculas.
Para evitar este lío, incluso en esta era de Unicode, no es aconsejable permitir el plegado de mayúsculas y los identificadores Unicode.
En el pasado, cuando el análisis y la compilación eran muy caros y llevaban toda la noche, era ventajoso para el compilador si no tenía que preocuparse por el caso.
Una vez que aparecieron 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.
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 dosis de expresividad a los nombres de los identificadores.
Desde el punto de vista de la sintaxis del lenguaje, puede forzar que ciertos identificadores comiencen con mayúsculas o minúsculas (por ejemplo, nombre de clase Java). Eso hace que el análisis sea más fácil y, por lo tanto, ayuda a mantener la sintaxis limpia.
Desde el punto de vista de un desarrollador, esto permite una gran cantidad de convenciones de codificación convenientes, lo que hace que su código sea más claro y fácil de entender.
Hay otra razón por la que los idiomas son sensibles a mayúsculas y minúsculas Los identificadores pueden almacenarse en una tabla hash y las tablas hash dependen de funciones hash que darán diferentes valores hash para diferentes casos. Y puede que no sea conveniente convertir todos los ID a todos los superiores o inferiores antes de ejecutarlos a través de la función hash. Me encontré con este problema cuando escribía mi propio compilador. Era mucho más simple (más perezoso) declarar mi lenguaje como sensible a mayúsculas y minúsculas.
He leído todo este hilo. Debo creer que aquellos que informan que han encontrado valor en la sensibilidad de mayúsculas / minúsculas nunca han programado en un verdadero lenguaje de alto nivel (que por definición no distingue entre mayúsculas y minúsculas). K & R admite que C es de nivel medio. Después de programar en Pascal, Delphi, Lazarus, ADA, etc., uno aprende que un código altamente legible es simple de escribir y de ejecutar rápidamente sin obsesionarse con constructos sensibles a las mayúsculas y minúsculas. Después de todo, la 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 un código que no distingue entre mayúsculas y minúsculas. Cuando uno desciende a un lenguaje de nivel medio, uno encuentra que NO hay ventajas para la distinción entre mayúsculas y minúsculas. Sin embargo, hay un número considerable de horas dedicadas a la depuración de problemas causados por la sensibilidad de las mayúsculas y minúsculas. Especialmente cuando se remendan módulos de diferentes codificadores. También parece que un gran número de encuestados no entiende qué se entiende por insensibilidad a las mayúsculas y minúsculas. Solo los caracteres az se ven afectados. Estos son un subconjunto secuencial de caracteres ASCII. Tres o cuatro bytes de código máquina hacen que el compilador sea indiferente al caso en este rango de caracteres. No altera debajo de la barra, numerales o cualquier otra cosa. Los puntos sobre otros idiomas y conjuntos de caracteres simplemente no se aplican a esta discusión. El compilador o el interruptor se codificarán para convertir temporalmente o no el carácter para su análisis en tiempo de compilación en función de que sea ASCII o no.
Estoy sorprendido de los nuevos lenguajes como Python que han salido repitiendo el error que cometió K & R. Sí, guardaron media docena de bytes en un entorno en el que la RAM total para el compilador, fuente y código de objeto era 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 son sensibles a mayúsculas y minúsculas. No creo que necesite usar "For" of "Print" como variable o nombre de función. Pero esa posibilidad se ha preservado por el costo del tiempo dedicado al contentamiento con el interruptor sobre el caso exacto de cada identificador. Un mal negocio, creo.
Lo más parecido que he leído hasta la fecha en apoyo de la distinción entre mayúsculas y minúsculas son los comentarios sobre Hashing. Pero estos raros eventos de codificación que pueden manejarse con una cuidadosa atención a los detalles no parecen valer la pena el inútil escrutinio que un codificador debe usar para escribir código sensible a mayúsculas y minúsculas. Dos vistas del problema. Uno fomenta la codificación incorrecta, establece trampas en el código y requiere atención adicional para desviarse de conceptos más grandes. El otro no tiene inconveniente, ha funcionado impecablemente en idiomas de alto nivel y permite flexibilidad si no daña. Me parece un caso más de victorias de VHS sobre BETA. Son solo mis dos centavos que valen aquí.
La mayúscula de una letra no es un concepto universal . Java usa Unicode, por lo tanto, si desea utilizar Java que no distingue entre mayúsculas y minúsculas, el significado de su programa podría cambiar según la configuración regional en la que se haya compilado.
La mayoría de los idiomas no le permiten poner puntos o comas (o apóstrofes o espacios) en el medio de literales enteros, probablemente porque también dependen de la configuración regional.
La sensibilidad de mayúsculas y minúsculas aumenta la legibilidad del idioma 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á distinguir entre el nombre de la clase y el nombre de la variable.
Además, tener Person, person, PersoN, PeRsOn, y PERSON, todos equivalentes tokens me daría un dolor de cabeza. :)
La sensibilidad de mayúsculas y minúsculas realmente no ayuda a la consistencia del caso.
Foo.Bar
foo.Bar
fOO.bAR
En un lenguaje insensible a mayúsculas y minúsculas que el editor puede corregir automáticamente. En un lenguaje de mayúsculas y minúsculas que lo soluciona, es más difícil, ya que puede ser legal. El editor primero tiene que saber si existen foo.Bar y fOO.bAR y también tiene que adivinar que escribió con el estuche incorrecto en lugar de olvidarse de declarar la variable (ya que Foo es diferente de fOO).
Mucha gente aquí ha dicho que sería malo para varias formas de capitalización referirse 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 las variables person, perSoN y PERSON todas refiriéndose a cosas diferentes, tiene un problema.
Muchos idiomas (que no son de programación) (por ejemplo, el europeo que utiliza el alfabeto romano) distinguen entre mayúsculas y minúsculas, por lo que es natural que los hablantes nativos de esos idiomas utilicen distinciones entre mayúsculas y minúsculas.
La sola idea de que los lenguajes de programación no distingan entre mayúsculas y minúsculas es un artefacto histórico que surge de las limitaciones del hardware de generación temprana (incluidas las máquinas de teletipo pre-computadora que usaban un código de caracteres de 5 bits).
Las personas que abogan por lenguajes que no distinguen entre mayúsculas y minúsculas deben ser incapaces de distinguir
IAmNowHere
de
IAmNowhere
( Es una broma! ;-)
No creo que obtengas una mejor respuesta que "porque el (los) autor (es) de ese idioma pensaban 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 nadie esté feliz de ver esto ...
Parece que la mayoría de la gente está de acuerdo en que la sensibilidad de mayúsculas y minúsculas es importante y estoy de acuerdo.
Sin embargo, puede ser molesto cuando tienes que escribir algo en el caso correcto, así que creo que el IDE debería permitirte escribir el caso incorrecto, pero si pulsas el atajo de autocompletar, debería hacer una coincidencia insensible a mayúsculas y minúsculas. Esto nos da lo mejor de ambos mundos.
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, puede elegir su convención, y otros codificadores pueden hacer lo mismo si comparten sus preferencias o no . Sin confusión
Tampoco pueden salirse con la tuya del genio que tiene una constante, función y variable, todas con el mismo nombre en el mismo archivo, aunque con diferentes topes. De nuevo, sin confusión.
¿Llamas a tu sitio web variable, llaman a su sitio web y qué sistema se confunde? Tampoco es una captura fácil, cuando estás escaneando.
En cuanto a las búsquedas, ¿es realmente mucho más procesamiento convertir el nombre a minúscula antes de buscarlo? Hacer una optimización prematura es una cosa, esperar que el desarrollador de su idioma de elección sea otro nivel completamente diferente.
... y, sin embargo, todas estas respuestas que dicen sensibilidad a casos reduce la confusión. Suspiro
También hay Common Lisp, que es un lenguaje que distingue entre mayúsculas y minúsculas y que muchas personas creen erróneamente que no distingue entre mayúsculas y minúsculas. Cuando escribe (car x) en el Oyente, se convierte en (CAR X) para su procesamiento. Es posible definir símbolos con nombres minúsculos, pero deben citarse con algo como |lower-case-symbol| . Por lo tanto, escribir en (car x) o (CAR X) o (Car X) todo funciona de la misma manera.
(Franz Lisp en un momento dado introdujo lo que llamaron capitalización "moderna", en la que el Oyente no doblaría los casos, y las palabras clave CL estarían en minúsculas. Nunca lo seguí lo suficientemente bien como para saber qué sucedió allí).
Todos los ejemplos que he visto soportan la sensibilidad de las mayúsculas y minúsculas se basan en el deseo de escribir código incorrecto y no descriptivo. por ejemplo, el argumento "fecha" frente a "miFecha"; estas prácticas son igualmente desacertadas y malas. Una buena práctica es nombrarlo en realidad: birthDate, hireDate, invoiceDate, lo que sea. Y quién en su sano juicio querría escribir un 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 el sensible código VB.Net. La idea de que la sensibilidad de mayúsculas y minúsculas le permite desobedecer aún más flagrantemente las buenas prácticas de programación es un argumento en contra, no por eso.
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 lenguajes naturales, pero bien podría no ser cierto para todos).
Hay una gran diferencia (donde vivo, de todos modos, cerca de la ciudad de Reading) entre:
Me gusta leer.
y
Me gusta leer.
Del mismo modo, si bien muchas personas capitalizan incorrectamente, y usted generalmente puede entender lo que significa, eso no significa que dicha escritura se considere correcta . Soy bastante riguroso en lo que respecta a este tipo de cosas, lo que no quiere decir que entiendo todas las cosas por mí mismo, por supuesto. No sé si eso es parte de la herencia de la distinción entre mayúsculas y minúsculas del lenguaje de programación, pero sospecho que sí.
Una ventaja distintiva de la distinción entre mayúsculas y minúsculas para los lenguajes de programación es que el texto se vuelve culturalmente insensible también. Ya es suficientemente malo tener que deletrear de vez en cuando a un compilador cuya codificación de texto se utiliza para un archivo fuente; tener que especificar en qué cultura se encuentra sería aún peor :(
Unix.
Unix era sensible a las mayúsculas y minúsculas, y muchos lenguajes de programación desarrollados para su uso en Unix eran sensibles a las mayúsculas y minúsculas.
Las computadoras no perdonan: un carácter en mayúsculas no es lo mismo que un carácter en minúscula, son completamente diferentes. Y cuando los ciclos de procesamiento, la RAM y demás eran costosos, no se consideraba que valiera la pena esforzarse para obligar a los compiladores y las computadoras a ser "indulgentes", la gente solo intentaba hacer que las cosas funcionaran.
Observe cómo la insensibilidad a las mayúsculas y minúsculas realmente no se convirtió en algo útil hasta que aparecieron cosas como Visual Basic . Una vez que las compañías comenzaron a invertir en el concepto de que programar a las masas era 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?
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É querrías?
Use nombres que tengan sentido , no:
function a(a)
{
int a = a.a;
return a
}
ExpertSexChange
Creo que este es un competidor de donde tienes que pagar para leer las respuestas. Hmm ... con insensibilidad de mayúsculas y minúsculas, el significado del nombre del sitio es ambiguo.
Esta es una buena razón para que los idiomas sean sensibles a mayúsculas y minúsculas. ¡Menos ambigüedad! La ambigüedad hacia los programadores se considera asquerosa.
Because people seriously overthink things.
Case insensitivity works best when it''s also case-preserving and combined with a separation between type and variable namespaces. This means that:
If you declare a class as ''
TextureImage'' and then try to use it as ''textureImage'', the IDE can autocorrect you. This gives you the advantage that you''ll never have to hit the shift key unless you''re declaring an identifier or using an underscore.Just like in Java and several other languages; it''s perfectly valid to type "
MyClass myClass". The IDE and the compiler should have no problem differentiating between the use of a type and the use of a variable.
In addition, case insensitivity guarantees that '' o '' and '' O '' will never refer to different objects. Common arguments include:
"
sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => and that someone will _never_ be allowed to join a programming team, so this is a strawman argument. even if they did manage to do so, case insensitivity is more the solution than the problem, because it means that you don''t have to remember whatever crazy uppercase/lowercase combination they use."you can''t internationalize case insensitivity easily!"; => over 95% of programming languages are written in english for a very good reason. there are no competing character encodings and the vast majority of keyboards on earth are english based (in partial or whole). supporting unicode identifiers is perhaps the dumbest idea anyone has came up with in the 21st century; because a good portion of unicode characters are frikkin invisible surragates, reading code is hard enough without having to use google translate, and writing code is hard enough without having to copy-paste identifiers or use a character map.
"but case sensitive languages have more identifiers!"; => no, they have grammatically overloaded identifiers, which is substantially worse.
I don''t use any case-insensitive languages, but the advantages are blatantly obvious if you think about this sort of thing seriously.
If word separation is not important then why do we put spaces between words? Therefore I think that underlines between words in a name do increase readability. Also lower case with Capitalization of appropriate characters is easiest to read. Lastly, it is surely much easier if all words can be conveyed by word of mouth - "Corporate Underscore Customer" rather than "Capital C Lower Case orporate Underscore Capital C Lower Case ustomer"! - the former can be spoken ''in one''s head'' the latter cannot - I wonder how people who are happy with case sensitivity handle these case sensitive names in their brains - I really struggle. So I feel that case sensitivity is not at all helpfull - a retrogade step from COBOL in my opinion.