Pourquoi la sensibilité à la casse existe-t-elle toujours dans certains langages de programmation?


44

Je ne vois aucune utilisation de la distinction entre majuscules et minuscules dans un langage de programmation, mis à part le code obscurcissant.

Pourquoi implémenter cela dans un langage de programmation?

Mise à jour:

On dirait que quelqu'un de votre connaissance a fait une déclaration à ce sujet .


28
Pourquoi existe-t-il toujours une insensibilité à la casse dans certains langages de programmation?
Thomas Eding

1
Même l'anglais est sensible à la casse en général. Les exemples couramment cités sont polonais et polonais qui sont deux termes différents dont les formes écrites ne diffèrent que par les cas et qui ont des prononciations et des significations différentes. IMO a intérêt à ce que la programmation ne soit pas trop intelligente à cet égard et laisse les programmeurs élaborer eux-mêmes les conventions écrites appropriées. Par exemple, il est assez courant d'écrire quelque chose comme Person person = new Person()dans le langage OO où le symbole 'personne' est un objet temporaire et 'Personne' est un type de classe.
Brandin

Réponses:


113

Le repli des cas est assez trivial en anglais, il l'est beaucoup moins dans d'autres langues. Si un programmeur allemand utilise ßun nom de variable, qu'allez-vous considérer comme son équivalent majuscule? Juste Pour votre information, « ß » 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 des caractères avec des marques diacritiques pré-composées ou des combinaisons de diacritiques combinées séparément. Ensuite, vous arriverez à quelques scripts arabes, avec trois formes distinctes de plusieurs lettres, au lieu de deux.

À l'époque sombre, la plupart des langages de programmation étaient insensibles à la casse, presque par nécessité. Par exemple, Pascal a commencé avec les ordinateurs centraux de données de contrôle, qui utilisaient seulement 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 ont des majuscules ou des minuscules, mais pas les deux, mais utilisent les mêmes codes pour les deux. Il en était de même pour les anciens codes Baudot et cette norme considérée dès les débuts de COBOL, FORTRAN, BASIC, etc. À l’époque où le matériel le plus performant était largement disponible, leur insensibilité à la casse était si profondément enracinée qu’il était impossible de la modifier. .

Au fil du temps, la véritable difficulté de l'insensibilité à la casse est devenue plus évidente et les concepteurs de langages ont surtout décidé ("se rendra compte" serait probablement un terme plus précis) que lorsque / si les gens veulent vraiment l'insensibilité à la casse, elle est mieux gérée par des outils auxiliaires. que dans la langue elle-même.

Au moins, IMO, le compilateur devrait prendre les entrées exactement telles qu’elles sont présentées, et non décider que "vous avez écrit cela, mais je vais supposer que vous vouliez vraiment dire autre chose". Si vous souhaitez que les traductions soient effectuées, il est préférable de les effectuer séparément, avec des outils conçus pour gérer cela correctement.


26
+1, allait dire quelque chose de similaire, d'après mon expérience, la plupart des gens qui gémissent à ce sujet sont les mêmes que ceux qui ne considèrent pas d'autres langues / jeux de caractères.
Jérémie Nunn

5
Ma grande question aussi, si le compilateur commence à remarquer des orthographes différentes, devrait-il vous permettre d'ajouter arbitrairement des traits de soulignement ou d'autres "séparateurs de mots"? Peut-être va-t-il essayer de "faire ce que vous attendez" lorsque vous mal orthographier un identifiant? Jusqu'où ira-t-il? (Au fait, Ada autorise les
traits de

3
@Barry: Les deux sont à peu près les mêmes - presque toutes les autres langues de la planète nécessitent des caractères qui ne sont pas disponibles en ASCII. En fait, même si nous nous débrouillons assez bien, c'est vraiment assez restreint, même pour l'anglais - par exemple, cela vous oblige à écrire "coopération" comme "coopération". Heureusement, les machines à écrire ont habitué les gens à de telles restrictions bien avant l'arrivée des ordinateurs, à tel point que peu de personnes envisagent même d'utiliser tous les caractères autrefois jugés nécessaires.
Jerry Coffin

2
@ dash-tom-bang: des compilateurs ont été écrits pour essayer de faire des choses comme ça (orthographe correcte et ce qui ne l'est pas). L'expérience montre qu'il est généralement préférable que le compilateur s'exécute plus rapidement et produise de meilleurs messages d'erreur.
Jerry Coffin

2
@phresnel ou "SZ". De bons arguments peuvent être avancés pour les deux.
Vatine

114

Pourquoi quelqu'un voudrait-il une insensibilité à la casse? Dans quel scénario est-il utile de pouvoir se référer à 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érerais de loin avoir une erreur de compilation lorsque je tape accidentellement VAriableau Variablelieu de laisser les dactylos majuscules comme celle-ci glisser dans mon code.

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


12
Vous le regardez de l'intérieur. Ouais, se référer à la même variable avec plusieurs orthographes peut être ennuyeux, mais c'est loin d'être aussi grave que d'avoir deux identifiants différents se référant à deux choses différentes, dans la même portée, qui ne diffèrent que par les cas. L'insensibilité à la casse est une bonne chose, car elle empêche cela. (De plus, cela empêche une simple faute de frappe de devenir une erreur de syntaxe; voir le lien dans la question au message de Jeff sur le sujet.)
Mason Wheeler

88
Mais je veux que les fautes de frappe simples soient des erreurs de syntaxe! Je ne veux pas de fautes de frappe simples dans mon code et je veux que mon compilateur m'aide à les trouver. L'insensibilité à la casse rend plus difficile leur recherche. L'insensibilité à la casse semble juste une excuse pour un codage négligé.
Nohat

4
@ nohat: Je suis d'accord, lorsque vous tapez autre chose que ce que vous avez l'intention de taper, une erreur de syntaxe est une bonne chose.
Tim Goodman

13
@Mason Wheeler, j'ai lu l'article et je ne pouvait simplement pas être plus en désaccord. J'ai utilisé de nombreux langages insensibles à la casse et je suis constamment exaspéré par les fautes de frappe.
Nohat

11
Absolument d'accord avec nohat - l'insensibilité à la casse est une idée ridicule - et les promoteurs viennent généralement de personnes qui aspirent toujours aux bonnes vieilles journées de VB / Basic.
Tim

27

En Java, la sensibilité à la casse n'est PAS utilisée pour fournir plus d'options en code, mais plutôt pour une signification sémantique très claire et cohérente. ClassesLookLikeThis. objetsLookLikeThis. methodLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. Cela n'offre PAS une plus grande liberté: cela vous permet d'intégrer des informations de manière concise dans un langage par ailleurs trop bavard.

Je pense que dans les langages explicitement typés statiquement avec le compilateur Mucho et le support IDE, la sensibilité à la casse est un excellent moyen de communiquer des informations (par exemple, Java). Avec des langages tels que Ruby, l’insensibilité à la casse produirait probablement PLUS de résultats inattendus, même si je serais ouvert à l’essai de Ruby.

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

      joe blah = new hUf();

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

      hUf.WTF();

En Java tel quel, vous sauriez automatiquement ce que c'est. En Java non sensible à la casse, c'est ambigu, vous devez donc recourir à un autre mécanisme pour différencier les classes des instances des packages à partir des méthodes. Et CE mécanisme vous ferait probablement vomir avec sa laideur :)


2
NOOOO! NON PLUS UNDERSCORES !! int package_class_method_var_name? !!
Michael K

2
@ Michael, étrange comment personne ne semble remarquer que le trait de soulignement est un problème à taper.
Dan Rosenstark le

2
cela dépend de votre clavier. Pour moi (avec un clavier français), _ est facile à taper, {} est beaucoup plus difficile (avec AltGr pour les atteindre).
PhiLho

6
Ah, donc la sensibilité à la casse est la nouvelle notation hongroise.
David Thornley

1
Ce n'est " sens sémantique très clair et cohérent " que si le compilateur l'impose. Désormais, un compilateur nécessitant que les noms de classe commencent par un caractère majuscule et les noms de méthode avec une minuscule pourrait constituer une raison intéressante pour être sensible à la casse.
Ross Patterson

24

Je ne pense pas que cela a été "implémenté" autant que "autorisé". La sensibilité à la casse est l'état par défaut des comparaisons de chaînes. L’ingénieur compilateur a besoin de plus de travail pour rendre une langue insensible à la casse, car vous devez ajouter du code supplémentaire pour effectuer des comparaisons ne respectant pas la casse et conserver les noms de jeton d'origine pour un rapport correct des erreurs et des avertissements.

C'est presque certainement pourquoi il s'est retrouvé en C; ils voulaient créer un langage simple sur lequel il serait facile de mettre en œuvre un compilateur, au détriment de la convivialité. Pourquoi c'est dans les langues modernes? Parce que c'est en C, bien sûr, alors ça doit être la bonne façon de le faire! </ mode sarcasme>


3
De plus, je pense que dans les années 60 et 70, lorsque les langages de programmation ont été inventés, l’espace et la vitesse sont TRÈS importants. Nous ne pouvons pas nous permettre ces instructions et cet espace supplémentaires pour les comparaisons insensibles à la casse. C'est plus un problème "c'est comme ça que ça a toujours été fait" dans les langues modernes. Il n'y a aucune raison pour que de nouvelles langues (comme C #) fassent cela.
Jay

1
@Jay: Et pourtant, pour une raison quelconque, Pascal, qui a précédé C et influencé sa conception, est insensible à la casse et compile encore plus rapidement. ;)
Mason Wheeler

@Mason: Je ne pensais pas que Pascal avait influencé C ... Je devais le rechercher. En gros, ils viennent tous d’Algol / Fortran! people.mandriva.com/~prigaux/language-study/diagram.png
Jay

1
@ Matt: Euh ... D'où tirez-vous cela? Toutes les ressources que j'ai vues datent de Pascal jusqu'en 1970 et de C jusqu'en 1972.
Mason Wheeler

16
Les enfants ces jours-ci. À l'époque, nous n'avions pas de minuscules et cela nous plaisait. 6 bits suffisaient. Bien sûr, maintenant nous sommes tous sourds du Cri.
KeithB

23

Si rien d'autre, cela simplifie l'analyse et vous permet plus de combinaisons pour les noms de variables / classes.

Avec une analyse non sensible à la casse, vous seriez limité à utiliser des identifiants uniques, puisque "myClass" et "MyClass" seraient la même chose. Sinon, vous devrez ajouter des couches de complexité à votre analyseur pour pouvoir déterminer quel identificateur est utilisé en fonction du contexte.

Considérons 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". Est-ce que vous l'appelez sur l'instance ou sur la classe, s'il n'y a pas de respect de la casse ici?


14
Thats mauvaise convention de nommage cependant. Je voudrais étrangler quelqu'un si writeet Writeétaient deux méthodes complètement différentes.
TheLQ

5
Je suis d'accord avec TheLQ sur celui-ci. Cela me rend fou quand je travaille dans une bibliothèque C et que je vois des déclarations du type "HWND hwnd;". Quiconque abuse de la sensibilité à la casse comme celui-ci doit être expulsé et tué.
Mason Wheeler

4
@TheLQ les méthodes ont le même cas. J'utilisais différents cas dans les noms de classe / variable comme exemple.
Adam Lear

6
@ Anne Lear, je pense que c'est un mauvais exemple. Avec un langage ne tenant pas compte de la casse, vous n'avez pas à vous soucier de la méthode à appeler car vous avez déjà une erreur de syntaxe en essayant d'utiliser un nom de classe pour un nom de variable.
Matt Olenik

5
@Matt, vous ne devriez pas coder sans mettre en évidence la syntaxe. Je peux comprendre sans IDE, mais coder dans un éditeur sans mettre en évidence la syntaxe ... pourquoi quelqu'un se ferait-il cela?
Davy8

13

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

En général, je programme en Python, mais il était très pratique de nommer des instances de classe de la même manière que la classe, mais dans le cas de C #, mais avec un cas inférieur (ou camel) (comme d'autres l'ont déjà dit):

Thing thing = new Thing();

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

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

Ce qui est une "mauvaise chose".

Je trouve également pratique de grep (tenir compte de la casse) pour trouver une référence à une classe par rapport aux utilisations d'une variable. Avec un langage insensible à la casse, cela serait moins facile. Même chose pour la recherche et le remplacement.

Enfin, en tant que programmeur, quand je vois des mots avec des cas différents, cela me fait comprendre que ce sont des choses différentes ... J'ai rarement des bogues où les cas variables étaient erronés, même dans des langages de script dynamiques où un compilateur aurait aidé.


10

Les gens sont attentifs à la forme des mots avant de les lire. La sensibilité à la casse permet de conserver la forme d'un symbole dans tout le code. Je suis également d’accord avec ceux qui précèdent, selon lesquels différentes conventions dénotent différents types de symboles. La sensibilité à la casse et l'insensibilité peuvent toutes deux être maltraitées. Les mauvais programmeurs généreront toujours du mauvais code ... ils trouveront un moyen.

Prenons le langage comme exemple. Pourquoi commençons-nous des phrases et des choses nommées avec des majuscules ... Est-ce aussi à cause d'Unix?


@JUST Les commentaires servent à demander des éclaircissements et non à prolonger la discussion. Si vous avez une solution, laissez une réponse. Si votre solution est déjà publiée, veuillez la revérifier. Si vous souhaitez discuter de cette réponse avec d'autres personnes, utilisez le chat . Voir la FAQ pour plus d'informations.
Adam Lear

9

Je pense que pour les langues à typage statique comme C # et Java, cela n’ajoute aucune valeur. Parce que dans la plupart des cas, vous avez un IDE qui corrigera automatiquement les mésappariements de cas, donc à la fin de la journée, si je tape "VAriable" par accident, mon IDE corrigera automatiquement cela pour " Variable "pour moi. Ajoutez à cela les MyClass myClass;conventions de style et vous pouvez voir que la sensibilité à la casse n'est pas nécessairement une mauvaise chose.

Pour les langages à 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 langages à typage dynamique, vous avez déjà tellement à vous préoccuper (en termes de l’utilisation d’une convention de boîtier cohérente ne va pas alourdir encore plus la charge.

Alors oui, alors il n'y a pas vraiment de langues raison pourrait ne pas être insensible à la casse, il y a aussi des raisons pas vraiment pourquoi ils devraient être non plus .

Cet article de Scott Hanselman sur "SignOn" vs "Signon" portait sur les comparaisons de chaînes et n'a rien à voir avec les langages de programmation. Je conviens que les chaînes que les utilisateurs tapent doivent toujours comparer les majuscules et les minuscules, mais je pense que les balises sont différentes des identificateurs utilisés dans un langage de programmation.


1
+1 pour avoir mentionné "l'IDE qui corrigera automatiquement les incohérences"
DavRob60

3
Les IDE sont pour les larbins. Je programme avec un crayon et du papier, puis scanne le code.
Dan Rosenstark

6

Quand une langue est sensible à la casse, j'en profite pour reproduire les cas classiques en mathématiques et en sciences. Voici une liste (non exhaustive) de certaines conventions de cas:

  • Dans la théorie des probabilités, les minuscules freprésentent généralement une fonction de densité de probabilité (pdf), tandis que les majuscules Frepré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 Xet 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 désigner des matrices, tandis que les lettres minuscules sont généralement utilisées pour désigner des nombres, par exemple, $ A = [a_ {ij}] $.
  • Les symboles d’unités sont écrits en lettres minuscules (par exemple, m pour mètre) sauf pour le litre (L) et pour les unités dérivées du nom d’une personne (W pour Watt, Pa pour Pascal, N pour Newton, etc.).
  • Les symboles de préfixes signifiant un million ou plus sont en majuscule (M pour méga (millions)) et ceux de moins d’un million sont en minuscules (m pour millièmes).

3
C'est un point valable, mais vous violeriez les conventions de codage de presque tous les langages de programmation courants, qui utilisent la sensibilité à la casse pour leurs propres besoins.
Ken Bloom

3

Je pensais que c'était à cause d'Unix et de C - mais c'est un problème de poule et d'œuf auquel seuls les geezers peuvent répondre correctement.

J'utilise l'argumentation que les poulets ont utilisée 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 venaient en premier. Par conséquent, parce que GCC fonctionne sous Unix, Unix est arrivé en premier, donc parce qu’Unix se soucie énormément de case, C et de toutes ses variantes et descendants, voire de tout ce qui impose des accolades, se soucie des cas.

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


Unix est apparu de nombreuses années avant GCC, mais le compilateur BCPL original était antérieur à Unix et créait généralement la "syntaxe C".
Ross Patterson

2

Outre les excellentes réponses apporté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 tels que BEGINet ENDqui fonctionnent à des moments différents du code normal (BEGIN au moment de la compilation, FIN après la fin du programme normal), et les avoir en majuscules les font ressortir et signifient que les minuscules les variantes ne sont pas des mots réservés.

On peut aller encore plus loin et réserver des noms en majuscules pour une utilisation future par le langage, et ne pas nuire aux programmeurs normaux, qui ne cèdent habituellement pas à leur code.


2

"Sensible à la casse" est toujours préférable pour les techniciens afin de réduire les ambiguïtés. Prenons le nom de fichier comme exemple. Traiter le nom de fichier Windows pose plus de problèmes que le nom de fichier Unix car le nom de fichier dans Windows ne respecte pas la casse, alors que le nom de fichier dans Unix est sensible à la casse.

Retour à la programmation. Pour le nom de la classe, le nom de la méthode, le nom de la variable, la plupart des langues n’appliquent pas la règle de style de nommage. Parfois, pour simplifier la réflexion, nous pouvons simplement utiliser le nom "Sensible à la casse" pour établir une liaison avec une autre source de données sans conversion, ou pour traiter le problème du même nom mais dans des cas différents.


Absurdité. Cela semble uniquement réduire l'ambiguïté, car vous vous attendez déjà à un comportement sensible à la casse.
Ross Patterson

1

Je suis surpris par ce discours. Maintenant que personne ne veut que vous utilisiez un trait de soulignement ou un m_nom de champ en C #, je viens d'utiliser une casse de chameau et si le nom du champ est identique à un nom de propriété publique, il suffit que le nom de la propriété publique soit casse Pascal et je pense que le support est l'affaire des chameaux, "ainsi soit-il" - c'est ce que semble souhaiter la communauté de la programmation dans son ensemble. Cela n'a posé aucun problème jusqu'à présent.


0

Certains programmeurs proviennent notamment des débuts de BASIC, dans lesquels un nom de variable ne peut contenir que 2 caractères.

Et ainsi, quand il peut y avoir un nombre quelconque de personnages, ils deviennent très heureux. Et avec la sensibilité à la casse - parce qu'ils ne veulent pas aussi se soucier d' SomeNameêtre égaux accidentellement SOMENAMEet de causer un bogue à cause de choses comme ça.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.