Pourquoi de nombreuses langues sont-elles sensibles à la casse?

StackOverflow https://stackoverflow.com/questions/503218

  •  20-08-2019
  •  | 
  •  

Question

Pourquoi de nombreuses langues sont-elles sensibles à la casse?

Est-ce simplement une question d'héritage? C ++ est sensible à la casse parce que C l'est, Java est sensible à la casse parce que C ++ est, etc.? Ou y a-t-il une raison plus pragmatique derrière cela?

Était-ce utile?

La solution

Unix.

Unix était sensible à la casse, et de nombreux langages de programmation développés pour être utilisés sous Unix étaient sensibles à la casse.

Les ordinateurs ne pardonnent pas - un caractère majuscule n’est pas la même chose qu’un caractère minuscule, ils sont complètement différents. Et à l'époque où les cycles de traitement, la mémoire vive, etc., coûtaient cher, cela ne valait pas la peine de forcer les compilateurs et les ordinateurs à & "Pardonner &"; Les gens essayaient simplement de faire fonctionner les choses .

Notez que l'insensibilité à la casse n'est pas vraiment devenue utile jusqu'à ce que des choses comme Visual Basic soient disponibles. Une fois que les entreprises ont commencé à s’investir dans le concept voulant que programmer les masses soit une bonne chose (par exemple, Microsoft gagne plus d’argent s’il ya plus de programmes sous Windows), les langues ont-elles commencé à être plus amicales et plus tolérantes.

Autres conseils

Je ne pense pas que vous obtiendrez une meilleure réponse que & ", car l'auteur (les auteurs) de cette langue a pensé que c'était mieux ainsi &" ;. Personnellement, je pense qu'ils ont raison. Je détesterais trouver ces lignes n'importe où dans le même fichier source (et faire référence au même objet + méthode) ... 

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

Je ne pense pas que quiconque serait heureux de voir cela ...

Une chose intéressante à considérer est que l'anglais est également sensible à la casse. (Je pense que cela est vrai pour la plupart des langues naturelles, mais cela peut ne pas être vrai pour tous.)

Il y a une grande différence (là où j'habite, près de la ville de Reading) entre:

  

J'aime lire.

et

  

J'aime lire.

De même, si de nombreuses personnes ne capitalisent pas correctement et que vous pouvez généralement comprendre ce que cela veut dire, cela ne signifie pas qu'une telle écriture est considérée comme correcte . Je suis un collant quand il s'agit de ce genre de choses, ce qui ne veut pas dire que tout va bien moi-même, bien sûr. Je ne sais pas si cela fait partie de l'héritage de la sensibilité à la casse en langage de programmation, mais je suppose que c'est peut-être le cas.

Un avantage distinct de la casse pour les langages de programmation est que le texte devient également insensible à la culture . Il est déjà assez pénible d’indiquer de temps en temps au compilateur quel encodage de texte est utilisé pour un fichier source - il serait encore pire de spécifier la culture dans laquelle il se trouve: (

C’est en fait extrêmement pratique, à la fois pour le développeur et pour la spécification de la syntaxe du langage: la distinction entre majuscules et minuscules ajoute beaucoup d’expressivité à la désignation des identifiants.

Du point de vue de la syntaxe du langage, vous pouvez forcer certains identifiants à commencer par une majuscule ou une minuscule (par exemple le nom de la classe Java). Cela facilite l’analyse et permet donc de garder la syntaxe propre.

Du point de vue des développeurs, cela permet un grand nombre de conventions de codage pratiques, rendant votre code plus clair et plus facile à comprendre.

Je suppose que la sensibilité à la casse élargit l’espace de noms. Un truc sympa comme 

MyClass myClass;

serait impossible avec un compilateur insensible à la casse.

Le casse est simple en anglais seulement (et pour tous les caractères < 128). L’allemand sz ou & Quot; sharp s & Quot; (& # 223;) n'a pas de variante en majuscule dans le jeu de caractères ISO 8859-1. Il n'en a reçu qu'un seul en Unicode après environ une décennie de discussions . (et maintenant, toutes les polices doivent être mises à jour ...). Les kanji et les hiragana (alphabets japonais) ne connaissent même pas les minuscules.

Pour éviter ce gâchis, même à l'ère de l'Unicode, il n'est pas judicieux d'autoriser le regroupement de casse et les identifiants Unicode.

À l'époque où l'analyse et la compilation étaient très coûteuses et prenaient toute la nuit, il était avantageux pour le compilateur de ne pas avoir à se soucier de la casse.

Une fois que les identificateurs ont été créés, leur retour est devenu très difficile. Beaucoup de développeurs l'ont aimé et il ne semble pas y avoir de grande volonté de l'annuler.

ExpertSexChange

Je pense que c’est un concurrent de Stack Overflow où vous devez payer pour lire les réponses. Hmm ... avec l'insensibilité à la casse, la signification du nom du site est ambiguë.

C’est une bonne raison pour que les langues soient sensibles à la casse. Moins d'ambiguïté! L’ambiguïté vis-à-vis des programmeurs est considérée comme dégoûtante.

La sensibilité à la casse ajoute à la lisibilité du langage par l’utilisation de conventions de dénomination. Vous ne pouvez pas écrire 

Person person = new Person("Bill");

si votre langage ne respecte pas la casse, car le compilateur ne serait pas en mesure de faire la distinction entre le nom de la classe et le nom de la variable.

De plus, le fait d’avoir une personne, une personne, une Perso, une PERSONNE et une PERSONNE équivalentes me donnerait mal à la tête. :)

Quelle est la forme capitale de i ? I (U + 0049) ou & # 304; (U + 0130)?

La capitalisation dépend des paramètres régionaux.

De nombreux langages (hors programmation) (par exemple, l’anglais utilisant l’alphabet latin) respectent la casse. Il est donc naturel que les locuteurs natifs de ces langues utilisent des distinctions majuscules / minuscules.

L'idée même que les langages de programmation ne soit pas sensible à la casse est un artefact historique découlant des limitations du matériel de la première génération (y compris les machines de télétype pré-informatiques utilisant un caractère 5 bits). code).

Les personnes qui plaident pour des langues sans distinction de cas doivent être incapables de distinguer 

IAmNowHere

de 

IAmNowhere

( C'est une blague! ; -)

Parce qu’ils sont aussi stupides qu’une boîte de grenouilles , précisément pour les raisons données pour le point de vue opposé dans ce fil (je ne vais même pas demander ce qu’il en est. Du bois pour les arbres et tout ça).

Lorsque FOOBAR = FooBar = foobar, vous devez choisir votre convention et les autres développeurs peuvent faire de même qu'ils partagent votre préférence ou non . Pas de confusion.

Ils ne peuvent pas non plus s’échapper avec le coup de génie qui consiste à avoir une constante, une fonction et une variable portant tous le même nom dans le même fichier, mais avec des majuscules différentes. Encore une fois, pas de confusion.

Vous appelez votre variable WebSite, ils appellent leur site Web et quel système est confus? Pas facile à attraper non plus, lorsque vous numérisez.

En ce qui concerne les recherches, est-ce vraiment beaucoup plus de traitement pour convertir le nom en minuscule avant de le rechercher? Faire votre propre optimisation prématurée est une chose, l’attendre de la part du développeur du langage de votre choix est un tout autre niveau de manque de sens.

... et pourtant, toutes ces réponses indiquant une sensibilité à la casse réduisent la confusion. Soupir

Il existe également Common Lisp, un langage sensible à la casse que beaucoup de personnes pensent, à tort, ne pas la distinguer. Lorsque vous tapez (car x) dans le récepteur, il devient (CAR X) pour le traitement. Il est possible de définir des symboles avec des noms en minuscules, mais ils doivent être cités avec quelque chose comme |lower-case-symbol|. Par conséquent, taper (Car X) ou <=> ou <=> fonctionne de la même manière.

(Franz Lisp introduisit à un moment donné ce qu'ils appelaient & "la > capitalisation moderne), dans laquelle l'auditeur ne se plierait pas les cas, et les mots clés CL seraient en minuscules. Je ne l'ai jamais assez bien suivie. pour savoir ce qui s’est passé là-bas.)

La casse d'une lettre n'est pas un concept universel . Java utilise Unicode. Par conséquent, si vous vouliez utiliser Java sans distinction de casse, le sens de votre programme pourrait changer en fonction des paramètres régionaux dans lesquels il a été compilé.

La plupart des langues ne vous permettent pas de mettre des points ou des virgules (ou des apostrophes ou des espaces) au milieu de littéraux entiers, probablement parce que cela dépend également de la localisation.

De Guide du développeur .NET Framework Conventions de capitalisation , respect de la casse:

  

Les directives de capitalisation existent   uniquement pour faciliter l'identification des identifiants   lire et reconnaître. L'enveloppe ne peut pas être   utilisé comme moyen d'éviter le nom   les collisions entre les éléments de la bibliothèque.

     

Ne supposez pas que toute la programmation   les langues sont sensibles à la casse. Elles sont   ne pas. Les noms ne peuvent pas différer selon les cas   seul.

Comment criez-vous si vous n’AVEZ PAS DE CAPS?! AHHH!

Vous devez être expressif. Mais en toute honnêteté, parmi tous les peuples du monde, ceux qui travaillent avec la logique de programmation seraient les premiers à insister sur le fait que les différences sont en réalité des différences.

La sensibilité à la casse n’aide pas vraiment la cohérence des cas. 

Foo.Bar  
foo.Bar  
fOO.bAR

Dans un langage non sensible à la casse pouvant être corrigé facilement par l'éditeur. Dans un langage sensible à la casse, il est plus difficile de le réparer, car cela peut être légal. L’éditeur doit d’abord vérifier si foo.Bar et fOO.bAR existent et aussi deviner que vous avez saisi le mauvais cas plutôt que d’oublier de déclarer la variable (car Foo est différent de fOO).

Beaucoup de gens ici ont dit qu'il serait mauvais que plusieurs formes de capitalisation se réfèrent à la même chose, par exemple: 

person
perSoN
PERSON

Ce qui serait vraiment dommage, c’est que ces éléments fassent tous référence à différents objets dans le code. Si vous avez des variables personne, personne et personne se référant toutes à des choses différentes, vous avez un problème.

Tous les exemples que j'ai vus dans la prise en charge de la sensibilité à la casse reposent sur le désir d'écrire du code incorrect, non descriptif. par exemple. la " date " " myDate " argument - ce sont à la fois indifféremment descriptifs et les mauvaises pratiques. La bonne pratique consiste à nommer ce qu'il est réellement: date de naissance, date d'embauche, date de facturation, etc. Et qui, dans son esprit, voudrait écrire du code tel que: 

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

C’est étonnant que cela soit parfaitement le cas dans dans le code VB.Net sensible. L’idée que la sensibilité à la casse vous permet de désobéir de manière encore plus flagrante aux bonnes pratiques de programmation est un argument contre elle, pas pour elle.

Parce que de nombreuses personnes trouvent employeeSocailSecurityNumber aussi lisible que employee_social_security_number et qu’elle est plus courte.

Je pense qu'avoir un langage sensible à la casse incite les gens à écrire du code de mauvaise qualité. 

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

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

Duh. Vous ne pouvez pas imaginer un meilleur nom de variable que & "ShoeSize &"; à des fins différentes? Vous pouvez utiliser un milliard de mots différents, mais vous choisissez de continuer à utiliser ShoeSize à la place?

Et vous pourriez aussi (bêtement) simplement utiliser des lettres simples (& "a &" et & "b &" et & "c &" ;) pour toutes les classes, variables, fonctions et méthodes.

Mais POURQUOI voudriez-vous?

Utilisez des noms qui ont du sens , et non: 

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

Il y a une autre raison pour laquelle les langues sont sensibles à la casse. Les identifiants peuvent être stockés dans une table de hachage et les tables de hachage dépendent de fonctions de hachage qui donneront des hachages différents selon les cas. Et il peut ne pas être pratique de convertir tous les identifiants en tous les identificateurs supérieurs ou inférieurs avant de les exécuter via la fonction de hachage. Je suis tombé sur ce problème en écrivant mon propre compilateur. C'était beaucoup plus simple (paresseux) de déclarer ma langue comme sensible à la casse.

J'ai lu tout ce fil de discussion. Je dois croire que ceux qui déclarent avoir trouvé un intérêt pour la sensibilité à la casse n'ont jamais programmé dans un langage réellement de haut niveau (qui, par définition, est insensible à la casse). K & Et R admettent que C est à mi-niveau. Après avoir programmé en Pascal, Delphi, Lazarus, ADA, etc., on apprend que le code hautement lisible est simple à écrire et à s'exécuter rapidement sans être obsédé par les constructions sensibles à la casse. Après tout, la lisibilité est le premier et le dernier mot du sujet. Le code est écrit pour l'homme, pas pour l'ordinateur. Aucun problème à déboguer avec un code insensible à la casse. Lorsqu'on passe à un langage de niveau moyen, on s'aperçoit que la sensibilité à la casse ne présente AUCUN avantage. Il y a cependant un nombre considérable d'heures passées à déboguer des problèmes de sensibilité à la casse. Surtout lorsque vous corrigez des modules de différents codeurs. Il semble également qu'un grand nombre de répondants ne comprennent pas ce que l'on entend par insensibilité à la casse. Seuls les caractères a-z sont affectés. Il s’agit d’un sous-ensemble séquentiel de caractères ASCII. Trois ou quatre octets de code machine rendent le compilateur indifférent aux majuscules de cette plage de caractères. Il ne modifie pas la barre inférieure, les chiffres ou quoi que ce soit d'autre. Les points relatifs aux autres langues et jeux de caractères ne s'appliquent tout simplement pas à cette discussion. Le compilateur ou l'interrupteur serait codé pour convertir temporairement ou non le caractère pour analyse au moment de la compilation, en fonction de son caractère ASCII ou non.

Je suis choqué par les nouveaux langages, tels que Python, qui répètent l'erreur que K & a commise. Oui, ils ont économisé une demi-douzaine d'octets dans un environnement où la RAM totale du compilateur, du code source et du code de l'objet était de 1000 octets. C'était alors. Maintenant, la mémoire n'est pas un problème. Maintenant, sans raison valable, même les mots réservés en Python sont sensibles à la casse! Je ne pense pas que j'aurai besoin d'utiliser & "Pour &"; de " Imprimer " comme variable ou nom de fonction. Mais cette possibilité a été préservée par le coût du temps passé à se contenter de l'interrupteur sur la casse exacte de chaque identifiant. Une mauvaise affaire je pense.

Les commentaires sur le hachage sont la chose la plus proche que j’ai lue à ce jour à l’appui de la sensibilité à la casse. Mais ces rares événements de codage qui peuvent être traités avec une attention particulière aux détails ne semblent pas valoir la peine de scrupules inutiles qu'un codeur doit utiliser pour écrire du code sensible à la casse. Deux points de vue du problème. L'une encourage les mauvais codes, installe des pièges dans le code et requiert une attention particulière pour être détournée des grands concepts. L'autre n'a pas d'inconvénient, a parfaitement fonctionné dans les langages de haut niveau et permet une certaine flexibilité s'il ne nuit pas. Il me semble qu’un autre cas de VHS l'emporte sur BETA. Ce ne sont que mes deux centimes d’ici.

Apprendre est toujours plus facile par l'exemple, alors voici:

C # (sensible à la casse, mais utilisable depuis VB.NET sans tenir compte de la casse): 

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 et JS utilisent un style similaire à C # mais les méthodes / fonctions / événements sont déclarés comme des variables doSomething, onEvent.

ObjectPascal (Delphi et Lazarus / FPC ne respectent pas la casse, comme ADA et 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

L'utilisation de OneCase et de préfixes pour chaque type est utile dans toutes les langues. Même les langues qui ont commencé sans préfixes ont des constructions plus récentes, comme des interfaces qui ne reposent pas sur la casse mais utilisent plutôt un préfixe.

Donc, ce n'est vraiment pas important si une langue est sensible à la casse ou non. Des concepts plus récents ont été ajoutés aux langages sensibles à la casse qui étaient trop déroutants pour être exprimés par des cas uniquement et qui nécessitaient l'utilisation d'un préfixe.

Depuis que les langages sensibles à la casse ont commencé à utiliser des préfixes, il est raisonnable d'arrêter d'utiliser des majuscules avec le même identifiant. nameIdentifier SomeIdentifier

Considérez ce problème: Vous avez un membre de classe appelé quelque chose, un paramètre de méthode / fonction appelé quelque chose et une variable locale appelée quelque chose, quelle convention de cas pourrait-on utiliser pour différencier facilement ces éléments? N’est-il pas plus simple d’utiliser le plus de ConsistentCaseStyle partout et d’ajouter un préfixe?

Les fans de langages insensibles à la casse se soucient de la qualité du code, ils veulent juste un style. Parfois, ils acceptent le fait qu’une bibliothèque est mal écrite et utilisent un style strict alors que la bibliothèque peut ne pas avoir de style ou de code médiocre.

Les langages sensibles à la casse et insensibles exigent une discipline stricte. Il est donc plus logique de n’avoir qu’un seul style partout. Ce serait mieux si nous avions un langage qui utilise uniquement StrictCase, un style partout et des préfixes.

Il y a beaucoup de mauvais code C, la sensibilité à la casse ne le rend pas lisible et vous ne pouvez rien y faire. Dans un langage insensible à la casse, vous pouvez imposer un bon style à votre code sans réécrire la bibliothèque. Dans un langage StrictCase qui n’existe pas encore, tout le code aurait une qualité décente:)

On dirait que les gens sont généralement d'accord pour dire que la sensibilité à la casse est importante et je suis d'accord.

Cependant, il peut être gênant de devoir taper quelque chose dans le bon cas, je pense donc que l'EDI devrait vous laisser taper le mauvais cas, mais si vous cliquez sur le raccourci de saisie semi-automatique, il devrait faire la correspondance insensible à la casse. Cela nous donne le meilleur des deux mondes.

  

Selon les normes de codage habituelles, Personne serait une classe, un nom de variable, et PERSON une constante. Il est souvent utile d'utiliser le même mot avec une capitalisation différente pour signifier quelque chose de connexe mais légèrement différent.

Donc, si vous aviez trois membres du personnel dans votre entreprise, tous appelés Robert, vous les appelleriez Robert, Robert et ROBERT, voulez-vous? Et s’appuyer sur les gens pour savoir exactement lequel vous voulez dire?

Donnez-leur des adresses électroniques telles que Robert@widgets.com, robert@widgets.com et ROBERT@widgets.com si votre système de messagerie était sensible à la casse?

Le potentiel de violation non autorisée de données à caractère personnel serait énorme. Sans parler du fait que vous ayez envoyé le mot de passe racine de la base de données à l’employé mécontent sur le point d’être licencié.

Mieux vaut les appeler Bob, Robbie et Robert. Mieux encore, appelez-les Robert A, Robert B et Robert C si leur nom de famille était par exemple. Arthur, Banks et Clarke

Vraiment - pourquoi diable a-t-il une convention de nommage qui invite aux erreurs ou à la confusion, qui repose sur le fait que les gens sont très alertes? Êtes-vous à court de mots dans votre carnet de bord?

Et quant à la personne qui mentionne le truc soi-disant pratique & "MyClass myClass &"; - pourquoi pourquoi pourquoi? Vous empêchez délibérément de voir rapidement si une méthode utilisée est une méthode de classe ou une méthode d'instance.

De plus, vous avez perdu la possibilité d'informer davantage la prochaine personne qui lit votre code de l'existence particulière de la classe.

Par exemple.

Client précédent client

Client Nouveau Client

Client Corporate Client

Votre nom d'instance doit idéalement dire à votre collègue davantage que la classe sur laquelle il est basé!

Si la séparation des mots n’est pas importante, alors pourquoi mettons-nous des espaces entre les mots? Par conséquent, je pense que les soulignements entre les mots d’un nom augmentent la lisibilité. Il est également plus facile de lire les minuscules avec une majuscule des caractères appropriés. Enfin, il est certainement beaucoup plus facile de pouvoir communiquer verbalement tous les mots - & "Corporate Underscore Customer &"; plutôt que " C minuscule et majuscule C Majuscule C Majuscule ou C " ;! - le premier peut être parlé «dans la tête», le second ne le peut pas - Je me demande comment les gens satisfaits du respect de la casse gèrent ces noms sensibles à la casse dans leur cerveau - je me bats vraiment. Je pense donc que la sensibilité à la casse n’est pas du tout utile - une étape rétrograde de COBOL à mon avis.

Parce que les gens pensent trop sérieusement aux choses.

L’insensibilité à la casse fonctionne mieux lorsqu'elle est également préservée et combinée à une séparation entre les espaces de nom de type et de variable. Cela signifie que:

  • Si vous déclarez une classe en tant que 'TextureImage' et tentez ensuite de l'utiliser en tant que 'textureImage', l'EDI peut vous corriger automatiquement. Cela vous donne l'avantage de ne jamais avoir à appuyer sur la touche Maj. Sauf si vous déclarez un identifiant ou utilisez un trait de soulignement.

  • Comme en Java et dans plusieurs autres langages; il est parfaitement valide de taper " MyClass myClass " ;. L’IDE et le compilateur ne devraient pas avoir de problème à faire la différence entre l’utilisation d’un type et l’utilisation d’une variable.

En outre, l’insensibilité à la casse garantit que "o" et "O" ne feront jamais référence à des objets différents. Les arguments courants incluent:

  • & "; sOmEoNe wIlL tYpE cOdE lIkE tHiS &" ;; = > et que quelqu'un ne sera jamais autorisé à rejoindre une équipe de programmation, il s'agit donc d'un argument Strawman. même s'ils y parviennent, l'insensibilité à la casse est plus la solution que le problème, car cela signifie que vous ne devez pas vous souvenir de la combinaison folle majuscule / minuscule qu'ils utilisent.

  • & "Vous ne pouvez pas internationaliser facilement l’insensibilité à la casse! &" ;; = > plus de 95% des langages de programmation sont écrits en anglais pour une très bonne raison. il n'y a pas d'encodage de caractères concurrents et la grande majorité des claviers sur Terre sont basés en anglais (en partie ou en totalité). La prise en charge des identifiants Unicode est peut-être l'idée la plus stupide que quelqu'un ait eu au 21ème siècle Parce qu'une bonne partie des caractères unicode sont des symboles frikkin invisibles, la lecture de code est assez dure sans avoir à utiliser Google Translate, et l'écriture de code est assez difficile sans avoir à copier-coller des identifiants ou à utiliser une mappe de caractères.

  • " mais les langages sensibles à la casse ont plus d'identificateurs! " ;; = > Non, ils ont des identifiants grammaticalement surchargés, ce qui est bien pire.

Je n'utilise pas de langage ne faisant pas la différence entre les majuscules et les minuscules, mais les avantages sont évidents si vous réfléchissez sérieusement à ce genre de chose.

Une réponse raisonnable pourrait être que les concepteurs de la langue l'ont pensé rendrait la langue plus facile à comprendre en pensant à l’avenir:)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top