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

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?

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.

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".

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.

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.

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.

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

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é.

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).

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).

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?

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 !!

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.

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.