Mots clés insensibles à la casse dans une langue [fermé]


31

Nous essayons d'écrire un langage de script personnalisé. Il a été suggéré de rendre la langue indulgente en fournissant des mots clés insensibles à la casse .

Personnellement, je n'aime pas l'idée, mais il y a peu de personnes dans mon équipe qui s'y penchent, disant que cela rendra l'utilisateur final heureux! Des exemples de langages comme FORTRAN, BASIC, SQL sont donnés en disant qu'ils ne sont pas sensibles à la casse.

Est-ce une bonne idée?


4
Eh bien, Visual Basic n'est généralement pas sensible à la casse, cela répond-il à votre question? ; P
yannis


3
Notez qu'il est très difficile de rendre les identificateurs insensibles à la casse, sauf si vous limitez les utilisateurs au jeu de caractères ASCII.
Simon Richter

2
@MainMa: au moins C ++ ne le fait pas directement. Il autorise les caractères définis par l'implémentation dans l'identifiant, mais ce qui est garanti est seulement a-zA-Z, 0-9(sauf au début) et _.
Xeo

2
VB6 utilise en fait une sorte d'approche hybride: vous pouvez écrire des mots-clés et des identifiants comme vous le souhaitez et l'EDI les convertit immédiatement en méthode stockée. (Vous pouvez même écrire "endif" et il sera converti en "End If".)
Felix Dombek

Réponses:


42

Demandez-vous qui est l'utilisateur final. S'il est destiné à être écrit par quelqu'un ayant une expérience de programmation en C ou Javscript, ou une expérience informatique sous Unix, alors la sensibilité à la casse est probablement la bonne chose à faire, car c'est ce que l'utilisateur attend. Mais pour la plupart des utilisateurs finaux, même les utilisateurs avancés, cela sera source de confusion.

VB / VBA / VBScript ne sont pas sensibles à la casse, et cette décision a été prise pour permettre aux non-programmeurs de se familiariser facilement avec le langage. Les formules Excel, pas exactement des scripts mais aussi proches que de nombreux utilisateurs, ne sont pas sensibles à la casse. Dans la plupart des écrits, le choix de la casse peut donner au texte un aspect plus ou moins professionnel et raffiné, mais le cas ne changera pas le sens sémantique des mots. C'est pourquoi je crois que les non-développeurs seront confus par un langage de script sensible à la casse.

Encore une fois, ce n'est pas un choix technique. C'est un choix de gestion de produit qui doit être fait par des personnes qui connaissent bien le public cible.


Réfléchissez aux systèmes de fichiers qui respectent la casse avant d'examiner les langages de programmation. FAT / NTFS pour Windows et HFS + pour MacOS X ne respectent pas la casse, tandis que UFS / NFS pour Unix sont sensibles à la casse. Les utilisateurs expérimentés aiment la possibilité de distinguer les fichiers / variables par de minuscules différences tandis que la plupart des utilisateurs préfèrent garder les choses plus intuitives. Comme le dit Avner, la différence est un choix de gestion de produit.
Michael Shopsin le

4
Puisqu'il s'agit d'un langage de script, c'est une évidence - l'insensibilité à la casse est la voie à suivre. Pourquoi être sensible à la casse? Si la réponse est "d'être comme C et Java", est-ce vraiment une bonne raison?
Ben

15
@Ben Python, Ruby, bash, Lua et Perl sont des exemples de langages de script très populaires qui respectent la casse. Les langages insensibles à la casse incluent les langages d'entreprise comme Delphi et SQL (et COBOL IIRC, si vous comptez). Pourquoi est-ce une évidence pour les langages de script, et pourquoi les concepteurs des plus grands langages de script du monde ne sont-ils pas d'accord?

2
Cela ne peut pas être une évidence en raison d'être un langage de script - la question pertinente est: qui fait le script et quel est le meilleur choix pour eux? (Je dirai également que vous devriez probablement être cohérent: si vos mots clés ne respectent pas la casse, veuillez ne pas rendre les identifiants sensibles à la casse ...)
comingstorm

@delnan Je pense que c'est un choix logique que le langage de script ciblant le système d'exploitation où la sensibilité à la casse est intégrée devrait également être sensible à la casse.
Artemix

16

Vous devez décider en fonction de l'expérience utilisateur que vous souhaitez présenter, et non de la facilité ou de la difficulté de mise en œuvre.

Si cela facilitera l'insensibilité à la casse pour vos utilisateurs, c'est ce que vous devez mettre en œuvre.

Par exemple, SQL n'est pas sensible à la casse. Cela le rend très facile à utiliser dans un cadre interactif.

Une autre façon de voir les choses est la suivante: y aura-t-il jamais une différence entre keywordet Keyworddans votre langue, et cette différence sera-t-elle significative pour l'utilisateur? Pour un langage de script, je dirais que la réponse est "non".


3
+1 pour "cette différence sera-t-elle significative pour l'utilisateur". L'utilisateur compte avant tout.
Ben

Pourquoi SQL est-il plus facile à utiliser dans un cadre interactif en raison de l'insensibilité à la casse? Est-ce parce que vous pouvez accidentellement activer le verrouillage des majuscules sans le remarquer?
Kaz

@Kaz - À peu près.
ChrisF

11

Les langages de programmation doivent être sensibles à la casse, point. Les gens peuvent s'y adapter très facilement: ils doivent simplement se rappeler de travailler principalement en minuscules et de faire attention aux identificateurs à casse mixte ou à majuscules dans les API existantes.

Il semblait autrefois évident de rendre les langues insensibles à la casse. En effet, les minuscules n'étaient pas disponibles sur tous les systèmes informatiques et leurs périphériques d'E / S (claviers, imprimantes et périphériques d'affichage). Les implémentations de langage de programmation devaient accepter des programmes écrits en majuscules, car seuls ceux-ci pouvaient être affichés ou imprimés. Et pour cela, ils devaient être insensibles à la casse, car accepter les majuscules et être sensibles à la casse en même temps signifie rejeter les minuscules. Les minuscules étaient quelque chose que les programmeurs voulaient, mais ne pouvaient pas toujours avoir. Personne ne voulait vraiment travailler avec des programmes qui criaient en majuscules; c'était juste une limitation matérielle.

Pendant un certain temps, il était même courant de replier les boîtiers dans les terminaux. Si un terminal ne pouvait afficher que des majuscules, mais que vous deviez vous connecter à un système informatique prenant en charge les majuscules et les minuscules, le terminal plierait les minuscules en majuscules. Vous pensez que c'était il y a si longtemps? "Comme l'Apple II, l'Apple II Plus n'avait aucune fonctionnalité en minuscules." (http://en.wikipedia.org/wiki/Apple_II_Plus) Lorsque les utilisateurs des premiers ordinateurs Apple se connectaient à un BBS qui avait un contenu à casse mixte, l'émulateur de terminal (ou l'hôte) devait tout replier en majuscules. Les messages écrits en majuscules étaient courants sur les babillards à cette époque. Cette fonctionnalité se trouve toujours dans les systèmes d'exploitation de type Unix, comme le noyau Linux. Par exemple, tapez le stty olcucà l'invite de votre shell.La discipline de ligne Unix tty peut mapper les minuscules aux majuscules en sortie, et elle peut mapper les majuscules en minuscules en entrée. Cela vous permet de travailler dans un langage de programmation en minuscules, sur un terminal qui n'a pas de minuscules.

L'insensibilité à la casse est un concept dépassé d'une ère informatique révolue qui ne fonctionne pas très bien dans le monde moderne de l'informatique internationalisée. Étendez-vous cela dans d'autres langues? Et le français: considérez-vous que È et è sont équivalents? Ou japonais? Considérez-vous que hiragana et katakana ne sont que des cas, de sorte que フ ァ イ ル et ふ ぁ い る sont le même identifiant? La prise en charge d'une telle folie compliquera considérablement votre analyseur lexical, qui devra disposer de cartes d'équivalence de cas pour l'ensemble de l'espace Unicode.

Notez que les mathématiques sont sensibles à la casse. Par exemple, le sigma en majuscules peut désigner la sommation, tandis que le sigma en minuscules indique autre chose, comme l'écart-type. Cela peut se produire dans la même formule sans créer de difficultés. (Le langage de programmation rendra-t-il Σ et σ équivalents?)

L'orthographe anglaise est sensible. Par exemple, de nombreux noms propres correspondent à des noms ordinaires ou même à d'autres parties du discours. "peut" est un verbe, mais "mai" est un mois, ou le nom d'une femme. De plus, si un acronyme ou une abréviation est écrit en minuscules, cela peut prêter à confusion. SAT signifie test d'aptitude scolaire, tandis que "sat" est le participe passé de "sit". Les gens intelligents prêtent attention aux détails et capitalisent correctement.

Fondamentalement, tout nouveau langage de programmation créé depuis 1985 qui ne respecte pas la casse est POUR CEUX QUI CRIENT ENCORE DANS DES COURRIELS ET DES AFFICHAGES SANS UNE SECONDE PENSÉE.

Que faire si votre langue est utilisée comme cible de génération de code pour traduire du code dans une autre langue et que cette autre langue est sensible à la casse? Vous devrez en quelque sorte transformer tous les noms pour capturer la distinction. (Donc, affirmer que ce n'est pas une décision technique, et seulement une question de préférences émotionnelles du public cible, est ridicule.)

Regardez les problèmes gênants causés par la gestion des cas dans Windows, lorsque les fichiers sont importés d'un autre système d'exploitation. C'est un problème technique. Les systèmes de fichiers sensibles à la casse ont un problème avec les données étrangères qui ne respectent pas la casse.

Common Lisp a adopté l'approche idéale: les noms de symboles sont sensibles à la casse, mais lorsque les jetons sont lus, ils sont pliés en majuscules. Cela signifie que les jetons foo, fOO, FOOet Footous désignent le même symbole: le symbole dont le nom est stocké sous forme de la chaîne de caractères "FOO". En outre, ce comportement est uniquement la configuration de table de lecture par défaut. Le lecteur peut plier des lettres en majuscules, en minuscules, inverser la casse ou la conserver. Les deux derniers choix donnent naissance à un dialecte sensible à la casse. De cette façon, les utilisateurs ont la flexibilité maximale.


1
"Et le français: considérez-vous que È et è sont équivalents? Ou japonais? Considérez-vous que l'hiragana et le katakana ne sont que des cas, de sorte que フ ァ イ ル et ふ ぁ い る sont le même identifiant?" La réponse est "oui", et ce n'est de la folie que si vous pensez que les cultures des autres sont stupides.
Ben

Eh bien, préparez-vous à ce que votre petite tête explose, car je ne pense pas que les cultures des autres soient stupides (à quelques exceptions près, en ce qui concerne les événements du monde), mais en même temps, je pense qu'il est complètement idiot de traiter フ ァ イ ル etふ ぁ い る comme le même identifiant dans un langage de programmation.
Kaz

@Vous connaissez les cultures mentionnées? Si vous saviez de quoi Kaz parlait, vous ne le qualifieriez pas de stupide.
David Cowden

1
@DavidCowden, je n'ai jamais appelé Kaz stupide. Je suis d'accord que l'on devrait toujours utiliser le même cas partout où l'on utilise un identifiant. La différence de Kana est plus significative que la différence de cas, tout comme la différence d'accent est plus significative que la différence de cas. Cependant, tout comme il est idiot d'avoir deux identifiants qui ne diffèrent que par la casse, il est également idiot d'avoir deux identifiants qui ne diffèrent que par kana ou par accent. Il est plus logique d'interdire les identificateurs ne différant que par le kana ou l'accent que de les traiter de la même manière, mais il est très peu logique de les traiter comme différents.
Ben

Si vous interdisez les identifiants qui ne diffèrent que par la casse, l'accent, le kana ou autre, alors vous admettez tacitement qu'ils sont les mêmes (mais insistant uniquement sur la cohérence). Il vaut mieux ne pas bannir de telles choses et les laisser aux utilisateurs comme une question de convention de codage. Une meilleure idée serait d'avoir un système déclaratif par lequel le programme peut affirmer cela fooet Foodoit être traité comme des synonymes ou comme distincts. Sans une telle déclaration, c'est une erreur pour les deux de se produire. Et puisque la déclaration ne s'étend pas à FOO, alors elle FOOest toujours interdite; il faut l'ajouter.
Kaz

6

Le véritable facteur déterminant est la fréquence à laquelle vous voudrez avoir plusieurs choses avec le même nom. L'insensibilité à la casse fonctionne en SQL car ce n'est pas souvent que vous voulez une colonne nommée SELECT. Ce serait ennuyeux en Java car chaque ligne ressemble à celle Object object = new Object()où vous voulez que le même nom fasse référence à une classe, une instance et un constructeur.

En d'autres termes, la sensibilité à la casse est surtout utile pour surcharger un nom, et la surcharge est surtout utile dans les grands projets complexes. Pour une utilisation plus rare, comme un langage de script, l'insensibilité à la casse peut rendre la programmation beaucoup plus simple.

J'ai fait un langage de règles une fois où les identifiants n'étaient pas seulement insensibles à la casse, ils étaient insensibles aux espaces. J'ai également autorisé la création d'alias faisant référence au même identifiant. Par exemple, ProgrammersStackExchange, les programmeurs Exchange Exchange et PSE ont tous résolu avec le même symbole exact et pourraient être utilisés de manière interchangeable.

Pour mon domaine, cela fonctionnait très bien, car le domaine avait beaucoup de façons extrêmement bien connues de se référer à la même chose, et les conflits de noms étaient rares. Personne ne serait surpris de saisir une requête en utilisant un nom et de faire en sorte que le résultat en utilise un autre. La prise en charge du langage a rendu la traduction entre le domaine et le langage de programmation très facile. Cependant, cela a également rendu certaines tâches plus difficiles, comme trouver toutes les références à une variable. Heureusement, dans mon cas, ce genre de situations est survenu rarement, ou était assez facile à créer un support d'outils pour vous aider, mais vous devez tenir compte de votre propre situation.


Je ne pense pas que vouloir réutiliser des mots clés pour les noms soit le problème. SQL, Visual Basic et C # (les deux premiers ne respectant pas la casse et le dernier sensible à la casse) résolvent tous deux cela en permettant un moyen de citer les identifiants: "double quotes"(ou [brackets]dans MS SQL) en SQL, [brackets]en VB.net et @atsignen C #.
Random832

"combien de fois vous voudrez avoir plusieurs choses avec le même nom." L'insensibilité à la casse signifie que vous devez ajouter des frais généraux pour lever l'ambiguïté des noms qui seraient autrement traités par la casse (par exemple, m comme préfixe pour «membre» pour distinguer d'un nom de propriété non préfixé, par exemple).
nwahmaet

Pourquoi nommeriez-vous un objet objet? Cela demande juste des ennuis.
Ben

@Ben, supposons que vous implémentez un objet conteneur, comment allez-vous appeler le paramètre à votre méthode add?
Winston Ewert

@WinstonEwert, je l'appellerais o. Peu importe vraiment comment vous l'appelez, car ce n'est qu'un nom de paramètre. Tant qu'il n'est pas offensant ou illégal, ou susceptible de créer de la confusion .
Ben

5

Supposons que votre langage de script soit sensible à la casse - allez-vous créer un compilateur ou un vérificateur de syntaxe qui dira à l'utilisateur s'il fait une faute de frappe en utilisant la mauvaise casse dans un nom de variable ou un mot-clé? Sinon, ce serait un argument très fort pour rendre la langue insensible à la casse.


Bon point, mais pas de réponse.

@delnan: peut-être pas une réponse aussi bonne que celle d'Avner Shahar-Kashtan (à qui j'ai donné +1), mais probablement utile pour l'OP.
Doc Brown

3
Ouais, utile comme commentaire;)

Donc, si cela est reformulé pour dire que ce n'est qu'une bonne idée si vous avertissez l'utilisateur de la sensibilité à la casse, ce serait une réponse? Pour moi, cela a été supposé.
JeffO

Non, alors ce serait un point mineur qui ne répond guère à la question formulée comme une réponse. A MON HUMBLE AVIS.

4

Pouvez-vous déclarer des variables à la volée? Si c'est le cas, je plaiderais contre la casse, car la recherche d'un bogue causé par

ATypo = 42; 

par opposition à

Atypo = 42; 

demande inutilement du temps de débogage, alors que le fait d'avoir les deux instructions équivalentes facilite la vie


2
À mon humble avis, il facilite également la lecture. Après tout, lorsque vous commencez une phrase, vous mettez en majuscule le premier mot, mais vous ne changez pas sa signification. Il devrait en être de même pour le code!
NWS

2
@delnan - vous vouliez la lisibilité, il utilise le même alphabet, pourquoi changer le sens quand on change de casse?
NWS

1
@delnan, selon la Cour suprême des États-Unis d'Amérique, les langages informatiques sont un langage expressif conçu pour être compris à la fois par les ordinateurs et les humains (en statuant que le code informatique est protégé par le premier amendement). Ils ne sont pas anglais, mais ils sont une langue, et dire "BOB" est différent de "bob" est différent de "Bob" est idiot dans n'importe quelle langue destinée à être utilisée par les humains. Oui, nous pouvons apprendre à y faire face, mais ce n'est aucune excuse que ce soit.
Ben

2
@Ben Permettez-moi de faire une analogie. Contrairement aux langages de programmation, la notation mathématique est exclusivement réservée aux humains. L'argument habituel de l'insensibilité à la casse étant un artefact historique des ordinateurs anciens ne s'applique pas ici. Pourtant, je doute qu'un mathématicien soutienne cela aet Adevrait être interchangeable. Ils plaident constamment, sans aucune exception. Par exemple, dans certains contextes, les lettres majuscules sont utilisées pour les ensembles tandis que les lettres minuscules sont des membres de l'ensemble. Un autre exemple se produit en génie électrique, les minuscules étant dépendantes du temps et les majuscules étant indépendantes du temps ...

2
@Ben ... dans ces contextes et dans d'autres, je ne considère pas la sensibilité à la casse comme une restriction. Je le vois comme libérant des symboles redondants à utiliser de manière plus productive, à travers des conventions qui communiquent du sens à travers, entre autres, la capitalisation. Comme toute notation laconique spécifique au domaine, cela peut sembler étranger au profane, mais permet aux experts de communiquer mieux et plus rapidement.

2

Des exemples de langages comme FORTRAN, BASIC, SQL sont donnés en disant qu'ils ne sont pas sensibles à la casse.

La raison pour laquelle FORTRAN et SQL (et COBOL) ne respectent pas la casse est qu'ils ont été initialement conçus pour être utilisés sur des machines où les jeux de caractères normaux n'avaient que des lettres majuscules. L'insensibilité à la casse dans ces langues (au moins) est plus un artefact historique qu'un choix de conception de langue.

Maintenant, vous pourriez faire valoir que l'insensibilité à la casse est plus indulgente, mais le revers de la médaille est que la sensibilité à la casse se traduit par un code plus lisible, car il se fonde sur le contrôleur pour utiliser la compatibilité avec la compatibilité.


4
J'en ai marre de l'argument "X est bon, Y applique la chose connexe Z, donc Y fait du bien en appliquant X" (par exemple, style de codage sain / Python / règle de hors-jeu). Aucun bon programmeur ne capitalise d'une manière qui affecte sérieusement la lisibilité, même lorsqu'il y est autorisé. Ceux qui abusent de l'insensibilité à la casse capitalisent également de manière incohérente dans un environnement sensible à la casse (et commettent une centaine d'autres atrocités), ils sont juste obligés d'utiliser la même mauvaise capitalisation pour chaque utilisation d'un nom individuel. Les mauvais programmeurs peuvent écrire Fortran dans n'importe quelle langue. (Avertissement: je suis un grand fan de la sensibilité à la casse!)

Devine quoi. J'en ai assez de devoir lire du code écrit par de mauvais programmeurs qui pensent qu'ils sont de si bons programmeurs qu'ils peuvent développer leurs propres règles de style uniques. (Avertissement: J'ai appris à programmer à l'époque de FORTRAN et COBOL, et je déteste l'insensibilité à la casse et d'autres atrocités linguistiques de cette époque.)
Stephen C

Toute utilisation de majuscules que ce soit dans un langage insensible à la casse constitue un abus d'insensibilité.
Kaz

@Kaz - erm ... essayez de le dire à un million de programmeurs SQL.
Stephen C

1

La sensibilité à la casse est considérée comme nuisible.

La vie n'est pas sensible à la casse, ni les utilisateurs ni les programmeurs.

Les langages sensibles à la casse sont un accident historique, des systèmes contraints qui ont trouvé des comparaisons insensibles à la casse difficiles. Ce handicap n'existe plus, il n'y a donc aucune raison de refaire un système informatique sensible à la casse.

J'irais jusqu'à dire que la sensibilité à la casse est mauvaise , car elle met la commodité de l'ordinateur avant celle de l'utilisateur.

(Lié, je me souviens il y a quelques années, un génie a refusé de payer sa facture de carte de crédit parce que son nom était en majuscules, mais il l'a épelé cas mixte. Par conséquent, a-t-il soutenu, il ne lui était pas correctement adressé et n'était une demande de paiement valable. Le juge a traité l'argument comme il le méritait).


La sensibilité à la casse ne fait pas passer la commodité de l'ordinateur avant celle de l'utilisateur. J'ai implémenté des langages sensibles à la casse et insensibles à la casse, et la seule différence est un appel de fonction supplémentaire à quelques endroits. En outre, d' autres réponses disent que le cas dans -sensibilité est un artefact historique en raison de jeux de caractères limités - contredit votre théorie, non?

Unicode place cela dans un tout autre domaine.
DeadMG

3
Ce blog ne donne aucune justification pour expliquer pourquoi il est mauvais en C, uniquement en Python ou PHP - et l'OP ne parle pas d'identificateurs sensibles à la casse, seulement des mots clés . Ce lien n'a absolument rien à dire sur ce sujet.
DeadMG

1
@Ben Editors peut (et fait) corriger la casse pendant que vous tapez, quelles que soient les règles de la langue. Autoriser les erreurs qui se glissent néanmoins (par exemple parce que vous n'avez pas d'éditeur sophistiqué à portée de main) n'aide pas. Cela signifie laisser un problème autour, au lieu de s'en plaindre pour le résoudre. De plus, une fois que j'utilise une capitalisation cohérente, je peux avoir plusieurs identifiants différents selon les cas, mais dénotant des choses très différentes et étant faciles à analyser pour les humains grâce au contexte et à la capitalisation, sans ambiguïté.

2
@Ben: Dans certaines langues, il existe des coutumes lexographiques très strictes, voire des règles. En C et C ++, la majuscule est une macro et les macros doivent rester majuscules pour éviter toute confusion. Certaines langues ont des significations différentes pour les symboles avec ou sans majuscules initiales (et je ne sais pas dans quelle mesure elles fonctionneraient dans diverses langues qui n'ont pas de lettres majuscules et minuscules correspondantes). Si vous avez des règles ou des conventions comme celle-ci, vous obtenez quelque chose de l'effet de différents espaces de noms, et la duplication des noms d'identificateurs dans différents espaces de noms fonctionne souvent.
David Thornley

1

D'après mon expérience personnelle, je ne vois pas de grande différence entre les langues sensibles à la casse et les langues insensibles.

Le plus important est le nommage et les conventions structurelles qu'un programmeur doit conserver dans son code et aucun compilateur ou analyseur ne le vérifie pour lui. Si vous vous en tenez à une sorte de règles, vous connaîtrez facilement un nom propre (vous ne penserez pas si vous avez nommé une variable checkOut ou CheckOut) et votre code sera probablement sensible à la casse et plus facile à lire.

Il ne faut pas utiliser CheckOut et checkOut et checkout et cHeCkOuT et CHECKOUT dans le même sens. Cela nuira à la lisibilité et rendra la compréhension de ce type de code plus difficile (mais il y a pire chose que l'on puisse faire pour détruire la lisibilité du code).

Si vous utilisez une sorte de règles, vous verrez par exemple:

CheckOut.getInstance () - c'est une méthode statique d'une classe appelée checkOut.calculate () - c'est une méthode d'un objet conservé dans une variable ou un champ public appelé _checkOut.calculate () - c'est une méthode d'un objet conservé dans un champ privé appelé CHECKOUT - c'est un champ / variable final statique ou constant

sans vérifier certains autres fichiers ou parties d'un fichier. Cela rend la lecture du code plus rapide.

Je vois pas mal de développeurs utilisant des règles similaires - dans des langages que j'utilise souvent: Java, PHP, Action Script, JavaScript, C ++.

Dans un cas rare, on peut être en colère contre l'insensibilité à la casse - par exemple lorsque vous souhaitez utiliser CheckOut pour un nom de classe et checkOut pour une variable et ne peut pas parce qu'il entre en collision les uns avec les autres. Mais c'est un problème de programmeur habitué à respecter la casse et à l'utiliser dans ses conventions de nommage. On peut avoir des règles avec des préfixes ou des postfixes standard dans un langage insensible à la casse (je ne programme pas en VB mais je sais que de nombreux programmeurs VB ont ce type de conventions de nommage).

En quelques mots: je vois mieux la sensibilité à la casse (uniquement pour les langages orientés objet) parce que la plupart des développeurs utilisent des langages sensibles à la casse et la plupart d'entre eux utilisent des conventions de dénomination basées sur la respect de la casse afin qu'ils aimeraient mieux qu'un langage soit sensible à la casse afin qu'ils le soient capable de s'en tenir à leurs règles sans aucune sorte de modifications. Mais c'est plutôt un argument religieux - pas un argument objectif (pas basé sur de vrais inconvénients ou de bons côtés de la sensibilité à la casse - parce que je n'en vois pas quand il s'agit d'un bon développeur, quand il s'agit d'un bAd DeVeLoPeR, on pourrait produire du code de cauchemar même quand il y a une sensibilité à la casse donc ce n'est pas une grande différence).


1

Les langages de programmation doivent être insensibles à la casse.

La raison principale pour laquelle tant de langues sont sensibles à la casse est simplement la conception de langage culte: «C l'a fait de cette façon, et C est incroyablement populaire, donc il doit être juste. Et comme dans tant d'autres choses, C s'est trompé sur celui-ci.

Cela fait en fait partie de la philosophie de conduite derrière C et UNIX: si vous avez le choix entre une mauvaise solution qui est facile à mettre en œuvre et une bonne solution qui est plus difficile à mettre en œuvre, choisissez la mauvaise solution et alourdissez la charge de contourner votre gâchis sur l'utilisateur. Cela peut ressembler à du snark, mais c'est absolument vrai. Il est connu comme le «pire est le meilleur principe», et il a été directement responsable de milliards de dollars de dommages au cours des dernières décennies en raison de C et C ++, ce qui rend beaucoup trop facile l'écriture de logiciels instables et non sécurisés.

Rendre un langage insensible à la casse est certainement plus facile; vous n'avez pas besoin des tables de lexers, d'analyseurs et de symboles pour avoir à faire le travail supplémentaire pour vous assurer que tout correspond d'une manière insensible à la casse. Mais c'est aussi une mauvaise idée, pour deux raisons:

  • Tout d'abord, surtout si vous construisez un langage de script, une simple faute de frappe où vous appelez quelque chose "myObject" à un endroit et "MyObject" à un autre, où vous faites évidemment référence au même objet mais qui est juste un peu incompatible avec la capitalisation , ne se transforme pas en erreur d'exécution. (Ceci est tristement célèbre comme un problème majeur dans les langages de script qui se trompent, comme Python.)
  • Deuxièmement, l'absence de respect de la casse signifie que la sensibilité à la casse ne peut pas être utilisée abusivement pour que le même mot se réfère à deux choses différentes dans la même portée simplement en changeant la capitalisation. Si vous avez déjà dû travailler avec du code Windows dans un environnement C et rencontrer des déclarations laides comme HWND hwnd;, vous saurez exactement de quoi je parle. Les gens qui écrivent comme ça oughtta doivent être retirés et abattus, et rendre le langage insensible à la casse empêche les abus de sensibilité à la casse de pénétrer dans votre code.

Faites donc l'effort supplémentaire pour bien faire les choses. Le code résultant sera plus propre, plus facile à lire, moins bogué et rendra vos utilisateurs plus productifs, et n'est-ce pas le but ultime de tout langage de programmation?


Les langages de programmation doivent avoir une portée lexicale pour détecter ce type d'erreur avant l'exécution (même s'ils sont par ailleurs très dynamiques). Common Lisp est un langage hautement dynamique, mais les compilateurs nous disent quand nous avons utilisé une variable qui n'a pas de liaison lexicale et qui n'était pas définie globalement comme une variable dynamique. Vous ne pouvez pas compter sur l'insensibilité à la casse pour cela car vous voulez attraper toutes les fautes de frappe, pas seulement celles impliquant la casse.
Kaz

Ça ne me dérange pas HWND hwnd;. C'est un exemple où la sensibilité à la casse fonctionne bien. La convention "Indian Hill" de type tout en majuscules est idiote. hwnd_t hwndc'est beaucoup mieux. Je soupçonne que c'est à cause de FILE. Il était une fois la version 6 Unix a dans son fichier d' en- tête bibliothèque E / S ceci: #define FILE struct _iobuf. C'était en toutes lettres car c'était une macro. Quand il est devenu un typedef en ANSI C, l'orthographe en majuscules a été conservée. Et je pense que c'est à l'imitation de cela que la convention ALL_CAPS_TYPE a été inventée et codifiée dans le Bell Lab "Indian Hill Style Guide. (L'original!)
Kaz

Si vous recherchez maintenant «Indian Hill Style Guide» sur Google, vous trouverez principalement des références à un document de 1990 des Bell Labs qui se repent complètement des noms de caractères en majuscules: aucune trace d'une telle recommandation. Mais la version originale recommandait des choses comme typedef struct node *NODE. Je suis sûr que c'est là que Microsoft doit avoir compris cela. Alors, blâmez les Bell Labs HWND.
Kaz

1

Je ne peux pas croire que quelqu'un ait dit "la sensibilité à la casse facilite la lecture du code".

Ce n'est certainement pas le cas! J'ai regardé par-dessus l'épaule d'un collègue les variables appelées entreprise et entreprise (entreprise publique variable, entreprise à variable privée assortie) et son choix de police et de couleur rend incroyablement difficile de faire la différence entre les deux - même lorsqu'ils sont côte à côte.

L'instruction correcte doit être "la casse mixte facilite la lecture du code". C'est une vérité beaucoup plus évidente - par exemple des variables appelées CompanyName et CompanyAddress plutôt que companyname. Mais aucun langage que je connaisse ne vous oblige à utiliser des noms de variables en minuscules.

La convention la plus folle que je connaisse est celle des "majuscules publiques, minuscules privées". C'est juste demander des ennuis!

Mon interprétation des erreurs est «mieux que quelque chose échoue bruyamment et le plus tôt possible plutôt que d’échouer discrètement mais semble réussir». Et il n'y a pas plus tôt que le temps de compilation.

Si vous utilisez par erreur une variable minuscule lorsque vous vouliez utiliser les majuscules, elle sera souvent compilée si vous la référencez dans la même classe . Ainsi, vous pouvez sembler réussir à la fois à la compilation et à l'exécution, mais faire subtilement la mauvaise chose, et peut-être ne pas le détecter pendant longtemps. Lorsque vous détectez qu'il y a un problème

Il vaut beaucoup mieux utiliser une convention où la variable privée a un suffixe - par exemple la variable publique Company, la variable privée CompanyP. Personne ne va accidentellement mélanger les deux, et ils apparaissent ensemble dans l'intellisense.

Cela contraste avec une objection que les gens ont à la notation hongroise, où une variable privée préfixée pCompany n'apparaîtrait pas à une bonne place dans l'intellisesne.

Cette convention présente tous les avantages de la terrible convention majuscule / minuscule et aucun de ses inconvénients.

Le fait que les gens ressentent le besoin de faire appel à la sensibilité à la casse pour distinguer les variables montre à la fois un manque d'imagination et un manque de bon sens, à mon avis. Ou, malheureusement, les moutons humains ont l'habitude de suivre une convention parce que "c'est comme ça que ça s'est toujours fait"

Rendez les choses avec lesquelles vous travaillez clairement et évidemment différentes les unes des autres, même si elles sont liées !!


1
D'accord companyName == companyname. Cela semble raisonnable, mais comment gérez-vous les paramètres régionaux? La compilation de votre programme dans différentes parties du monde provoquera-t-elle une sémantique différente, comme en PHP? Serez-vous complètement anglo-centrique et ne prendre en charge l'ensemble imprimable ASCII dans les identifiants? L'insensibilité à la casse est beaucoup plus complexe pour très peu de gain supplémentaire.
Phoshi

0

Vous ne devez pas introduire une insensibilité à la casse sans une très bonne raison de le faire. Par exemple, traiter des comparaisons de cas avec Unicode peut être une chienne. La sensibilité à la casse (ou son absence) des langues plus anciennes est sans importance, car leurs besoins étaient très différents.

Les programmeurs de cette époque s'attendent à la sensibilité à la casse.


1
Les comparaisons de cas ne sont pas si difficiles. Décomposez simplement vos identifiants. É = E '= e' = é. Rappelez -vous , vous pouvez toujours choisir qui cas les règles à suivre, et l' anglais est un choix raisonnable. (certainement si vos mots clés sont également en anglais)
MSalters

2
Oui, ils sont "si durs", sur tout l'espace Unicode.
Kaz

1
"Les programmeurs de cette époque s'attendent à la sensibilité à la casse"? Seulement s'ils souffrent du syndrome de Stockholm après avoir travaillé trop longtemps avec la famille C.
Mason Wheeler

Eh bien, la famille C ne représente, comme, qu'une très grande proportion de langues et de code. D'ailleurs, je pense que c'est une bonne chose et votre commentaire ne propose aucune raison pour laquelle ce n'est pas le cas.
DeadMG

0

La sensibilité à la casse rend le code plus lisible et la programmation plus facile.

  • Les gens trouvent que l'utilisation appropriée des cas mixtes est plus facile à lire .

  • Il permet / encourage CamelCase de telle sorte que le même mot avec une casse différente puisse faire référence à des choses liées: Car car; Ainsi la variable nommée carest créée de type Car.

  • ALL_CAPS_WITH_UNDERSCORES indique les constantes par convention dans de nombreuses langues

  • all_lower_with_underscores peut être utilisé pour les variables membres ou autre chose.

  • Tous les outils de programmation modernes (contrôle de source, éditeurs, diff, grep, etc.) sont conçus pour respecter la casse. Vous aurez toujours des problèmes avec les outils que les programmeurs tiennent pour acquis si vous créez un langage insensible à la casse.

  • Si la langue est interprétée, il peut y avoir une pénalité de performance pour l'analyse syntaxique insensible à la casse du code.

  • Et les caractères non anglais? Décidez-vous maintenant de ne jamais prendre en charge le copte, le chinois et l'hindi? Je vous suggère fortement de faire de votre langue par défaut tout en UTF-8 et qui prend en charge certaines langues qui ont des caractères sans équivalent en majuscule ou en minuscule. Vous n'utiliserez pas ces caractères dans vos mots clés, mais lorsque vous commencerez à désactiver la sensibilité à la casse dans divers outils (pour trouver des choses dans des fichiers par exemple), vous rencontrerez des expériences surréalistes et probablement désagréables.

Quel est l'avantage? Les 3 langues que vous mentionnez sont des années 1970 ou antérieures. Aucune langue moderne ne fait cela.

D'un autre côté, tout ce qui fait réellement plaisir à l'utilisateur final apporte un peu de lumière au monde. Si cela affectera vraiment le bonheur des utilisateurs, vous devez le faire.

Si vous voulez que ce soit vraiment simple pour les utilisateurs finaux, vous pouvez faire mieux que la sensibilité / insensibilité à la casse - jetez un œil à Scratch ! Quelques chats de dessins animés en moins et des couleurs plus conviviales pour les entreprises et vous avez la langue la plus amicale que j'ai jamais vue - et vous n'avez rien à écrire! Juste une pensée.


1
Je pense que vous vouliez dire "l'insensibilité à la casse est un cauchemar". Le japonais a un cas: les hiragana et les katakana sont, en quelque sorte, des cas différents. Tout comme A et a sont "identiques" d'une certaine manière, il en est de même pour あ et ア. Le katakana est parfois utilisé pour mettre l'accent, tout comme les majuscules dans les langues qui utilisent l'alphabet romain. Inutile de dire qu'il serait idiot de traiter hiragana et katakana de la même manière dans les identificateurs de langage de programmation.
Kaz

Merci - c'est enrichissant! J'ai nettoyé un peu mon message.
GlenPeterson

1
Car car;est l'un des meilleurs arguments contre la sensibilité à la casse: c'est moche, et si votre langue est insensible à la casse, vous ne pouvez pas abuser de la casse de cette façon.
Mason Wheeler

1
C'est Car myCar;tellement mieux?
GlenPeterson

@Mason Wheeler: Si nous limitons nos constructions linguistiques à celles que nous ne pouvons pas abuser, nous ne pourrons pas faire grand-chose, n'est-ce pas? Mon conseil à quiconque abuse de la sensibilité à la casse est "Ne pas".
David Thornley
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.