it-swarm.dev

Pourquoi la sensibilité à la casse est-elle toujours présente dans certains langages de programmation?

Je ne vois aucune utilité pour la sensibilité à la casse dans un langage de programmation, à part le code de brouillage.

Pourquoi implémenter cela dans un langage de programmation?

Mise à jour:

Il ressemble à quelqu'un que vous connaissez a fait une déclaration à ce sujet .

44
DavRob60

Bien que le pliage de cas soit assez banal en anglais, il l'est beaucoup moins dans d'autres langues. Si un programmeur allemand utilise ß dans un nom de variable, qu'allez-vous considérer comme l'équivalent en majuscules? Juste pour info, "ß" est seulement jamais utilisé en minuscules. OTOH, "ss" est équivalent - considéreriez-vous un compilateur obligé de les faire correspondre? Lorsque vous entrez dans Unicode, vous rencontrez des problèmes encore plus intéressants, tels que les caractères avec des signes diacritiques pré-composés par opposition aux combinaisons de signes diacritiques séparés. Ensuite, vous arrivez à certains scripts arabes, avec trois formes distinctes de plusieurs lettres, plutôt que seulement deux.

Dans les âges sombres, la plupart des langages de programmation étaient insensibles à la casse presque par nécessité. Par exemple, Pascal a commencé avec les mainframes Control Data, qui n'utilisaient que six bits par caractère (64 codes au total). La plupart de ces machines utilisaient le jeu de caractères "CDC Scientific", qui ne contenait que des caractères majuscules. Vous pouvez passer à d'autres jeux de caractères, mais la plupart avaient des majuscules ou des minuscules, mais pas les deux - mais utilisaient les mêmes codes pour les deux. Il en était de même pour les anciens codes Baudot et tels standards considérés dans les premiers jours de COBOL, FORTRAN, BASIC, etc. Au moment où du matériel plus performant était largement disponible, leur insensibilité à la casse était si profondément ancrée qu'il était impossible de le changer. .

Au fil du temps, la véritable difficulté de l'insensibilité à la casse est devenue plus apparente, et les concepteurs de langage ont principalement décidé ("réalisé" serait probablement un terme plus précis) que lorsque/si les gens veulent vraiment une insensibilité à la casse, il est préférable de la gérer par des outils auxiliaires. que dans la langue elle-même.

Au moins IMO, le compilateur devrait prendre les données exactement comme présentées, ne pas décider que "vous avez écrit ceci, mais je vais supposer que vous vouliez vraiment autre chose." Si vous voulez que les traductions se produisent, vous feriez mieux de les faire séparément, avec des outils conçus pour bien gérer cela.

114
Jerry Coffin

Pourquoi voudrait-on insensibilité à la casse? Dans quel scénario est-il utile de pouvoir faire référence à une seule variable comme VARIABLE à un endroit, Variable à un autre et variable à un troisième? L'insensibilité à la casse est exaspérante. Je préfère de loin obtenir une erreur de compilation lorsque je tape accidentellement VAriable au lieu de Variable plutôt que de laisser des fautes de casse comme celles-ci se glisser dans mon code.

En conclusion, de nombreux langages de programmation ont la casse non seulement pour des raisons historiques/inertielles, mais parce que l'insensibilité à la casse est une mauvaise idée.

116
nohat

Dans Java la sensibilité à la casse n'est PAS utilisée pour fournir plus d'options dans le code, mais plutôt pour une signification sémantique très claire et cohérente. ClassesLookLikeThis. ObjectsLookLikeThis. MethodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeTike. PAS fournir une plus grande liberté: il vous permet de regrouper certaines informations de manière concise dans ce qui est une langue autrement trop verbeuse.

Je pense que dans les langages explicitement typés statiquement avec le compilateur mucho et IDE, la sensibilité à la casse est un excellent moyen de communiquer des informations (par exemple, Java). Avec des langages comme Ruby, l'insensibilité à la casse serait probablement provoquer des résultats encore plus inattendus, mais je serais prêt à essayer Ruby insensible à la casse.

Je pense que la sensibilité à la casse avec un système strict n'obscurcit pas le code mais le rend plus clair. Considérez possible Java code:

      joe blah = new hUf();

c'est assez clair, mais qu'en est-il:

      hUf.WTF();

Dans Java tel quel, vous savez automatiquement de quoi il s'agit. Dans Java insensible à la casse, il est ambigu, donc vous devez recourir à un autre mécanisme pour différenciez les classes des instances des packages des méthodes. Et CE mécanisme vous ferait probablement vomir avec la laideur :)

27
Dan Rosenstark

Je ne pense pas qu'il ait été "mis en œuvre" autant que "autorisé". La sensibilité à la casse est l'état par défaut des comparaisons de chaînes; l'ingénieur du compilateur nécessite un travail supplémentaire pour rendre un langage insensible à la casse, car vous devez ajouter du code supplémentaire pour effectuer des comparaisons non sensibles à la casse et conserver les noms de jeton d'origine pour des rapports d'erreur et d'avertissement corrects.

C'est presque certainement pourquoi il s'est retrouvé en C; ils voulaient créer un langage simple et facile à implémenter un compilateur, au détriment de la convivialité. Quant à savoir pourquoi c'est dans les langages modernes? Parce que c'est en C, bien sûr, donc doit être la bonne façon de le faire! </ mode sarcasme>

24
Mason Wheeler

Si rien d'autre, il simplifie l'analyse et vous permet plus de combinaisons pour les noms de variable/classe.

Avec une analyse non sensible à la casse, vous seriez limité à devoir utiliser des identifiants uniques, car "maClasse" et "MaClasse" seraient la même chose. Alternativement, vous devrez ajouter des couches de complexité à votre analyseur pour vous assurer que vous pouvez déterminer quel identificateur est utilisé en fonction du contexte.

Prenons un cas comme celui-ci:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Supposons que la classe XmlWriter possède également une méthode statique appelée "Write". L'appelez-vous sur l'instance ou sur la classe, s'il n'y a pas de respect de la casse appliqué ici?

23
Adam Lear

J'aime la sensibilité à la casse si pour aucune autre raison que cela rend le code plus auto-documenté:

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

Je programme généralement en Python, mais dans mes jours C #, j'ai trouvé très pratique de nommer les instances de classe de la même manière que la classe, mais en minuscule (ou en chameau) (comme d'autres l'ont dit):

Thing thing = new Thing();

L'utilisation de langages insensibles à la casse nécessite une autre convention pour cela, c'est-à-dire une sorte de sigil comme:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Ce qui est une "mauvaise chose".

Je trouve également pratique de grep (en respectant la casse) pour trouver une référence à une classe par rapport aux utilisations d'une variable. Avec un langage insensible à la casse, ce serait moins facile. Idem pour la recherche et le remplacement.

Enfin, en tant que programmeur, quand je vois des mots avec des cas différents, il me semble que ce sont des choses différentes ... J'ai rarement des bugs où les cas variables étaient incorrects, même dans des langages dynamiques et scriptés où un compilateur aurait aidé.

13
Hollister

Les gens font attention à la forme des mots avant de les lire. La sensibilité à la casse maintient la forme d'un symbole cohérent dans tout le code. Je suis également d'accord avec ceux ci-dessus qui affirment que différentes conventions désignent différents types de symboles. La sensibilité à la casse et l'insensibilité peuvent être abusées. Les mauvais programmeurs généreront toujours du mauvais code ... ils trouveront un moyen.

Prenons l'exemple de la langue. Pourquoi commençons-nous des phrases et des choses nommées avec des majuscules ... Est-ce aussi à cause d'unix?

10
Tjaart

Je pense que pour les langages de type statique comme C # et Java, cela n'ajoute en fait aucune valeur. Parce que dans la plupart des cas, vous avez un IDE qui corrigera automatiquement les disparités de cas pour vous de toute façon, donc à la fin de la journée, si je tape "VAriable" par accident, mon IDE corrigera automatiquement cela à "Variable" pour moi. Ajoutez à cela le MyClass myClass; conventions de style et vous pouvez voir que la respect de la casse n'est pas nécessairement une mauvaise chose.

Pour les langues à typage dynamique, il pourrait y avoir plus d'argument, car il est plus difficile pour un IDE de deviner une autocorrection, mais dans le cas des langues à typage dynamique, vous l'avez déjà beaucoup plus à craindre (en termes de fautes de frappe) que l'utilisation d'une convention de casse cohérente ne va pas ajouter beaucoup plus de fardeau.

Alors oui, bien qu'il n'y ait pas de véritable raison pour que les langages pas soient insensibles à la casse, il n'y a pas non plus de vraie raison pour laquelle ils devraient l'être non plus.

Cet article de Scott Hanselman sur "SignOn" vs "Signon" portait sur les comparaisons de chaînes, et rien à voir avec les langages de programmation. Je suis d'accord pour dire que les chaînes qui les utilisateurs tapent doivent toujours comparer la casse de manière insensible, mais je pense que c'est un jeu de balle différent des identifiants dans un langage de programmation.

9
Dean Harding

Lorsqu'une langue est sensible à la casse, j'en profite pour reproduire l'utilisation conventionnelle des cas en mathématiques et en sciences. Voici une liste (nullement exhaustive) de quelques conventions de cas:

  • Dans la théorie des probabilités, les minuscules f représentent généralement une fonction de densité de probabilité (pdf), tandis que les majuscules F représentent la fonction de distribution cumulative correspondante (cdf).
  • Toujours dans la théorie des probabilités, les lettres majuscules désignent des variables aléatoires X et les lettres minuscules correspondantes désignent leurs réalisations x, comme dans $ Pr [X = x]\leq 0,05 $.
  • En algèbre linéaire, les lettres majuscules sont généralement utilisées pour faire référence aux matrices tandis que les lettres minuscules sont généralement utilisées pour faire référence aux nombres, par exemple, $ A = [a_ {ij}] $.
  • Les symboles d'unité sont écrits en lettres minuscules (par exemple, m pour mètre), sauf pour le litre (L) et les unités dérivées du nom d'une personne (W pour Watt, Pa pour Pascal, N pour Newton, etc.).
  • Les symboles des préfixes qui signifient un million ou plus sont capitalisés (M pour méga (millions)), et ceux de moins d'un million sont en minuscules (m pour milli (millièmes)).
6
A. N. Other

J'ai juste pensé que c'était à cause d'Unix et de C - mais c'est une sorte de poulet et le problème des œufs auquel seuls les geezers peuvent répondre correctement.

J'utilise le raisonnement utilisé par les poulets dans "Le lapin de Pâques arrive en ville" lorsqu'on leur a demandé s'ils étaient venus avant Eggs. Parce qu'il y avait des poulets sur l'arche de Noé, les poulets sont venus en premier. Par conséquent, parce que GCC fonctionne sur Unix, Unix est venu en premier, donc parce qu'Unix se soucie tellement de la casse, C et toutes ses variantes et descendants, oui tout ce qui impose des accolades, se soucie de la casse.

Il existe probablement également un lien entre les accolades et la sensibilité à la casse.

3
Peter Turner

"Respecter la casse" est toujours préférable pour les techniciens afin de réduire l'ambiguïté. Prenons l'exemple du nom de fichier. Gérer le nom de fichier Windows est plus problématique que le nom de fichier Unix car le nom de fichier dans Windows est insensible à la casse tandis que le nom de fichier dans Unix est sensible à la casse.

Retour à la programmation. Pour le nom de classe, le nom de méthode, le nom de variable, la plupart des langues n'appliquent pas la règle de style de dénomination. Parfois, par souci de simplicité pour faire de la "réflexion", nous pouvons simplement utiliser le nom "sensible à la casse" pour lier à une autre source de données sans conversion, ou gérer le problème du même nom mais dans des cas différents.

2
linquize

En plus des excellentes réponses données jusqu'à présent, je voudrais souligner que la sensibilité à la casse vous donne également des "espaces de noms" supplémentaires. Par exemple, Perl a des blocs spéciaux comme BEGIN et END qui s'exécutent à des moments différents du code normal (BEGIN au moment de la compilation, END après la fin du programme normal), et les avoir comme tous- les majuscules les distinguent et signifient que les variantes en minuscules ne sont pas des mots réservés.

On peut aller encore plus loin et réserver des noms tout en majuscules pour une utilisation future par le langage, et ne pas nuire aux programmeurs normaux, qui NE CRIENT généralement PAS DANS LEUR CODE.

2
moritz

Je suis surpris par cette diatribe. Maintenant que personne ne veut que vous utilisiez un trait de soulignement ou un m_ dans un nom de champ en C #, je viens d'utiliser le cas du chameau, et si le nom du champ est le même que le nom d'une propriété publique, juste que le nom de la propriété publique est le cas Pascal et le champ de support est le cas du chameau, je figure, "qu'il en soit ainsi" - c'est ce que la communauté de programmation dans son ensemble semble vouloir. Jusqu'à présent, cela n'a posé aucun problème.

1
Scott Whitlock

En particulier, certains programmeurs viennent des premiers jours de BASIC, où un nom de variable ne peut contenir que 2 caractères.

Et donc, quand il peut y avoir n'importe quel nombre de personnages, ils deviennent très heureux. Et avec la sensibilité à la casse - parce qu'ils ne veulent pas se soucier également que SomeName soit accidentellement égal à SOMENAME et provoque un bogue à cause de choses comme ça.

0
Michael W