Est-ce une mauvaise conception pour un langage de programmation de permettre des espaces dans les identifiants?
Certains ( lien 1 , lien 2 ) langages de programmation autorisent des espaces dans leurs identifiants (par exemple des variables, des procédures) mais la plupart d'entre eux ne le font pas et à la place les programmeurs utilisent généralement cas de chamea , cas de serpent et d'autres façons de séparer les mots dans les noms.
Pour prendre en charge les espaces ou même d'autres caractères Unicode, certains langages de programmation permettent d'encapsuler le nom avec un certain caractère pour délimiter son début et sa fin.
Est-ce une mauvaise idée d'autoriser des espaces ou est-ce que ce n'est généralement pas autorisé pour des raisons historiques (quand il y avait plus de limitations qu'aujourd'hui ou simplement décidé de ne pas être mis en œuvre)?
La question porte davantage sur les principaux avantages et inconvénients de sa mise en œuvre dans les langages de programmation nouvellement créés.
Considérer ce qui suit.
var [Example Number] = 5;
[Example Number] = [Example Number] + 5;
print([Example Number]);
int[] [Examples Array] = new int[25];
[Examples Array][[Example Number]] = [Example Number]
Comparez-le avec l'exemple plus traditionnel:
var ExampleNumber = 5;
ExampleNumber = ExampleNumber + 5;
print(ExampleNumber);
int[] ExamplesArray = new int[25];
ExamplesArray[ExampleNumber] = ExampleNumber;
Je suis presque sûr que vous avez remarqué que la tension de votre cerveau pour lire le deuxième exemple était beaucoup plus faible.
Si vous autorisez des espaces sur un identifiant, vous devrez mettre un autre élément de langage pour marquer le début et la fin d'un mot. Ces délimiteurs forcent le cerveau à effectuer une analyse supplémentaire et, selon celui que vous choisissez, créent un tout nouvel ensemble de problèmes d'ambiguïté pour le cerveau humain.
Si vous ne mettez pas de délimiteurs et essayez de déduire de quel identifiant vous parlez lorsque vous tapez du code par contexte uniquement, vous invitez un autre type de boîte de vers:
var Example = 5;
var Number = 10;
var Example Number = Example + Number;
int[] Examples Array = new int[25];
Examples Array[Example Number] = Example Number;
Example Number = Example Number + Example + Number;
print text(Example Number);
Parfaitement faisable.
Une douleur totale pour la correspondance des motifs de votre cerveau.
Ces exemples sont pénibles à lire non seulement à cause du choix des mots que je choisis, mais aussi parce que votre cerveau prend un peu plus de temps pour identifier ce est chaque identifiant.
Considérez le format plus régulier, encore une fois:
var Example = 5;
var Number = 10;
var ExampleNumber = Example + Number;
int[] ExamplesArray = new int[25];
ExamplesArray[ExampleNumber] = ExampleNumber;
ExampleNumber = ExampleNumber + Example + Number;
printText(ExampleNumber);
Avez-vous remarqué quelque chose?
Les noms des variables sont toujours terribles, mais la pression pour les lire a considérablement diminué. Cela se produit parce que votre cerveau a maintenant une ancre naturelle pour identifier le début et la fin de chaque mot, vous permettant d'abstraire cette partie de votre pensée. Vous n'avez plus à vous soucier de ce contexte - vous voyez une rupture dans le texte, vous savez que c'est un nouvel identifiant qui arrive.
Lors de la lecture du code, votre cerveau n'a pas beaucoup lu autant les mots qu'il correspond avec ce que vous avez en tête en ce moment. Vous ne vous arrêtez pas vraiment pour lire "ExampleWord". Vous voyez la forme générale de la chose, ExxxxxxWxxd, elle correspond à tout ce que vous avez caché dans votre tas mental, et ils vont lire. C'est pourquoi il est facile de passer à côté d'erreurs comme "ExampleWord = ExapmleWord" - votre cerveau ne le lit pas vraiment. Vous faites juste correspondre des choses similaires.
Une fois de plus, considérez ce qui suit:
Example Word += Example Word + 1;
Imaginez-vous maintenant essayer de déboguer ce code. Imaginez combien de fois vous manquerez cet espace supplémentaire sur "Exemple de mot". Une lettre mal placée est déjà difficile à détecter au premier coup d'œil; un espace supplémentaire est pire d'un ordre de grandeur.
En fin de compte, il est difficile de dire que permettre des espaces blancs rendrait le texte plus plus lisible. Je trouve difficile de croire que les tracas supplémentaires de terminateurs supplémentaires et les frais généraux supplémentaires sur mon cerveau valent la peine d'utiliser ce type de fonctionnalités si le langage avec lequel je travaille le possédait.
Personnellement, je considère que c'est une mauvaise conception - non pas à cause des tracas du compilateur, de l'interprète ou autre, mais parce que mon cerveau trébuche sur ces espaces en pensant que c'est un nouvel identifiant qui est sur le point de commencer, quand il ne l'est pas.
Dans un sens, notre cerveau souffre des mêmes problèmes que nos processeurs en ce qui concerne prédiction de branche .
Alors s'il vous plaît, soyez gentil avec nos pensées. Ne mettez pas d'espaces sur vos identifiants.
Est-ce une mauvaise conception pour un langage de programmation de permettre des espaces dans les identifiants?
Réponse courte:
Peut être.
Réponse légèrement plus longue:
La conception est le processus consistant à identifier et à pondérer les solutions conflictuelles à des problèmes complexes et à faire de bons compromis qui répondent aux besoins des parties prenantes. Il n'y a pas de "mauvaise conception" ou de "bonne conception" sauf dans le contexte des objectifs de ces parties prenantes , et vous n'avez pas dit quels sont ces objectifs. , la question est donc trop vague pour y répondre.
Réponse encore plus longue:
Comme je l'ai mentionné ci-dessus, cela dépend des objectifs de la circonscription que le concepteur de langage aborde. Prenons deux langages que je connais: la forme lisible par l'homme de MSIL, le "langage intermédiaire" de bas niveau que C # compile et C #.
C # est destiné à être un langage qui rend les développeurs de secteurs d'activité très productifs dans des environnements que Microsoft considère comme stratégiquement importants. En C #, un identifiant est une séquence d'un ou plusieurs caractères UTF-16 où tous les caractères sont classés comme alphanumériques ou _, et le premier caractère n'est pas un nombre.
Cette grammaire lexicale a été soigneusement choisie pour avoir des caractéristiques qui correspondent aux besoins de ces développeurs LOB stratégiquement importants:
- Il est sans ambiguïté lexable comme identifiant;
1e10par exemple ne doit pas être un identifiant légal car il est lexicalement ambigu avec un double. - Il prend en charge les idiomes couramment utilisés en C, C++ et Java, comme nommer un champ privé
_foo. C # a été conçu pour plaire aux développeurs qui connaissaient déjà un langage LOB commun. - Il prend en charge les identifiants écrits dans presque toutes les langues humaines. Vous voulez écrire
var φωτογραφία = @"C:\Photos";en C #, vous allez de l'avant. Cela rend la langue plus accessible aux développeurs qui ne sont pas anglophones natifs.
Cependant, C # ne prend pas en charge les espaces dans les identificateurs.
- Cela compliquerait la grammaire lexicale et introduirait des ambiguïtés qui doivent alors être résolues.
- Dans la grande majorité des situations d'interopérabilité, ce n'est pas nécessaire. Personne ne nomme ses membres publics pour y avoir des espaces.
C'était une bonne idée de interdire les caractères autres que les lettres et les chiffres dans les identificateurs C #.
Dans MSIL en revanche, vous pouvez nommer une fonction presque n'importe quoi, y compris mettre des espaces ou d'autres caractères "bizarres" dans les noms de méthode. Et en fait, le compilateur C # en profite! Il générera des "noms indescriptibles" pour les méthodes générées par le compilateur qui ne doivent pas être appelées directement par le code utilisateur.
Pourquoi est-ce une bonne idée pour MSIL et non C #? Parce que les cas d'utilisation MSIL sont complètement différents:
- MSIL n'est pas conçu comme un langage de développement principal; il s'agit d'un langage intermédiaire, le cas d'utilisation principal est donc pour les développeurs de compilateurs essayant de comprendre la sortie de leur compilateur.
- MSIL est conçu pour pouvoir interagir avec tout environnement de développement Microsoft hérité, y compris pre-.NET Visual Basic et autres OLE = Clients d'automatisation, qui autorisaient des espaces dans les identifiants.
- Comme indiqué ci-dessus, être capable de générer un nom "indescriptible" pour une fonction est une fonctionnalité, pas un bug.
Est-ce donc une bonne idée d'autoriser les espaces dans les identifiants? Cela dépend des cas d'utilisation de la langue. Si vous avez un cas d'utilisation solide pour le permettre, permettez-le certainement. Sinon, non.
Pour en savoir plus: Si vous voulez un exemple d'un langage fascinant qui fait un excellent usage des identifiants complexes, voir Inform7 , un DSL pour les jeux d'aventure basés sur du texte:
The Open Plain is a room.
"A wide-open grassy expanse, from which you could really go any way at all."
Cela déclare un nouvel objet de type room appelé The Open Plain, et cet objet peut ensuite être désigné comme tel dans le programme. Inform7 possède un analyseur très riche et complexe, comme vous pouvez l'imaginer.
Voici un exemple plus complexe:
Before going a direction (called way) when a room (called next location) is not visited:
let further place be the room the way from the location;
if further place is a room, continue the action;
change the way exit of the location to the next location;
let reverse be the opposite of the way;
change the reverse exit of the next location to the location.
Notez que way et next location et further place et reverse sont des identifiants dans cette langue. Notez également que next location et the next location sont aliasés. (Exercice: qu'est-ce que ce code fait à la structure de données qui maintient la carte des salles dans le jeu?)
Inform7 a une circonscription qui veut une langue anglaise d'apparence naturelle comme code source. Il semblerait étrange d'écrire ce Inform7 comme
change the way exit of the location to the_next_location;
Il est révolutionnaire de le faire. Comparez cela avec la (excellente) réponse de T. Sar qui fait le contraste - qu'il est révolutionnaire pour les développeurs dans les langages LOB d'essayer d'analyser mentalement où se trouvent les identifiants. Encore une fois, cela se résume au contexte et aux objectifs.
Un relativement bien connu exemple est celui d'un code Fortran dans lequel une seule faute de frappe a complètement changé la signification du code.
Il était prévu de répéter une section de code 100 fois (avec I comme compteur de boucle):
DO 10 I = 1,100
Cependant, la virgule a été typée comme un point:
DO 10 I = 1.100
Parce que Fortran autorise les espaces dans les identificateurs (et parce qu'il crée automatiquement des variables si elles n'ont pas été déclarées), la deuxième ligne est parfaitement valide: elle crée implicitement une variable réelle parasite appelée DO10I et lui attribue le numéro 1.1. Le programme s'est donc bien compilé sans erreur; il n'a tout simplement pas réussi à exécuter la boucle.
Le code en question contrôlait une fusée; comme vous pouvez l'imaginer, ce genre d'erreur aurait pu être catastrophique! Heureusement, dans ce cas, l'erreur a été détectée lors des tests et aucun vaisseau spatial n'a été endommagé.
Je pense que cela montre plutôt bien l'un des dangers à laisser des espaces dans les identifiants…
Est-ce une mauvaise conception pour un langage de programmation de permettre des espaces dans les identifiants?
Vous avez oublié des détails d'implémentation importants:
qu'est-ce que code source pour vous?
J'aime la définition de FSF : la forme préférée sur laquelle les développeurs travaillent. C'est une définition sociale, pas technique.
Dans certaines langues et leur implémentation des années 1980 (pensez aux machines originales Smalltalk et 1980 Smalltalk), le code source n'était pas une séquence de caractères. C'était un arbre de syntaxe abstraite et a été manipulé par l'utilisateur, avec la souris et le clavier, en utilisant une interface graphique.
Dans un certain sens, LISP commun accepte les espaces dans ses symboles.
Vous pouvez décider (c'est un beaucoup de travail) de co-concevoir à la fois votre langage de programmation ( documenté dans un rapport donnant les deux syntaxe et sémantique ), son implémentation (comme certains logiciels), et son éditeur ou IDE (comme certains logiciels).
Lisez les anciennes discussions sur tunes.org . Lisez l'ancien travail de l'INRIA sur
@TechReport{Jacobs:1992:Centaur,
author = {Jacobs, Ian and Rideau-Gallot, Laurence},
title = {a {\textsc{Centaur}} Tutorial},
institution = {\textsc{Inria} Sophia-Antipolis},
year = 1992,
number = {RT-140},
month = {july},
url = {ftp://www.inria.fr/pub/rapports/RT-140.ps}
}
et
@techreport{donzeaugouge:inria-mentor,
TITLE = {{Programming environments based on structured
editors : the \textsc{Mentor} experience}},
AUTHOR = {Donzeau-Gouge, Véronique and Huet, Gérard and Lang,
Bernard and Kahn, Gilles},
URL = {https://hal.inria.fr/inria-00076535},
TYPE = {Research Report},
NUMBER = {RR-0026},
INSTITUTION = {{INRIA}},
YEAR = 1980,
PDF =
{https://hal.inria.fr/inria-00076535/file/RR-0026.pdf},
HAL_ID = {inria-00076535},
HAL_VERSION = {v1},
}
Voir aussi mon Projet de rapport Bismon et http://refpersys.org/
Mon rêve RefPerSys est de co-concevoir un tel langage de programmation déclaratif avec un Nice IDE pour cela. Je sais que cela pourrait prendre une décennie. N'hésitez pas à penser que nous sommes fous, dans un certain sens nous sommes!
Du point de vue de l'utilisabilité, coloration de la syntaxe et autocomplétion est plus important que les espaces dans les identifiants (regardez dans les deux GtkSourceView et CodeMirror pour l'inspiration). Visuellement un trait de soulignement _ ressemble à un espace. Et si vous codez votre propre IDE, vous pourriez accepter ctrlspace comme entrée pour les "espaces dans les noms". Mon avis est que ℕ et ∀ devraient être des "mots-clés", la question devient comment les tapez-vous. Je rêve de taper (inspiré par LaTeX) \forallESC pour obtenir un ∀ (et j'ai entendu parler de certains sous-mode emacs pour cela).
NB: je déteste Python (et Makefile - s) car les espaces blancs (ou tabulations) y sont importants.
Il n'est pas intrinsèquement mauvais de concevoir autoriser espaces dans les noms de symboles. Cela peut être illustré par un simple contre-exemple.
Kotlin autorise les espaces dans les noms. Il a également des conventions de codage officielles qui indiquent quand il est correct d'utiliser cette fonctionnalité :
Noms des méthodes de test
Dans les tests (et uniquement dans les tests), il est acceptable d'utiliser des noms de méthode avec des espaces entre guillemets.
Exemple:
class MyTestCase { @Test fun `ensure everything works`() { /*...*/ }
"Bon" et "mauvais" est bien sûr subjectif, mais l'utilisation d'espaces dans les noms de méthode de test rend le code de test beaucoup plus agréable à lire, et teste également les résultats Agréable à lire, sans que le codeur de test doive se répéter en ayant un nom de méthode laid et une description de test lisible par l'homme séparément.
Le point important ici est que ces méthodes ne seront normalement pas appelées explicitement à partir de code écrit par des humains, donc seul l'endroit où le nom apparaît est dans la définition de la méthode. Je pense que c'est une distinction importante pour considérer quand les espaces peuvent être une bonne idée dans les noms de symboles: seulement lorsque le symbole n'est écrit qu'une seule fois par le programmeur.
Règle générale:
Les erreurs sont proportionnelles au temps nécessaire pour lire le code à haute voix.
Tout ce qui augmente le nombre de parenthèses ouvertes, fermées, accolades ouvertes, accolades fermées, parenthèses ouvertes, parenthèses fermées ... augmentera le nombre d'erreurs dans le code.
C'est une des raisons pour lesquelles * est une étoile ou un splat, et non un astérisque. # est chut,! est bang. Je suppose que les mathématiciens ont aussi de courtes expressions verbales pour leurs symboles.
C'est pourquoi les domaines technologiques se remplissent d'acronymes et d'abréviations: nous pensons en mots. Nous avons une durée d'attention finie et ne pouvons contenir que tant de symboles dans notre tête. Nous regroupons et regroupons donc les choses.
ReallyReallyLongIdentifier peut faire la même chose. Là, le compromis est entre se rappeler à quoi il sert et s'emmêler dans nos processus de pensée. Mais ReallyReallyLongIndentifer est toujours meilleur que QzslkjfZslk19
Plus il est éloigné de sa création, plus il doit être mémorable. Ainsi, i, j, k utilisés pour les constructions de boucles - comme les éphémères, ils vivent pendant la durée d'une boucle, et cette boucle commence et se termine sur le même écran.
Cela s'étend également au codage:
A = FunctionAlpha (21, $ C, $ Q)
B = FunctionBeta ($ A, $ D, $ R)
est plus propre que
B = FunctionBeta (FunctionAlpha (21, $ C, $ Q), $ D, $ R)
Je pense que c'est une des raisons pour lesquelles les feuilles de calcul ont de tels taux d'erreur abyssaux mauvais codage: sauf en ajoutant des cellules/lignes/colonnes temporaires, il n'y a aucun moyen d'éviter les instructions imbriquées désordonnées.
Il m'a fallu beaucoup de temps pour vraiment comprendre qu'il n'y aurait jamais vraiment de meilleure langue. Pour une équipe de programmation, les aspects les plus importants sont que le langage soit bien connu, pris en charge par de nombreux outils, devrait avoir une syntaxe linguistique minimale et devrait vous surprendre aussi rarement que possible.
Pour un seul codeur, un langage puissant qui permet des cycles de test/exécution rapides est excellent.
Pour un administrateur, une langue adaptée à la langue du shell du système d'exploitation est essentielle.
Pour certaines langues de travail partagées entre les disciplines, les DSL peuvent être agréables.
Y a-t-il une place pour une langue avec des espaces - probablement. Il viole les règles non surprenantes mais correspond très bien aux objectifs DSL.
Une chose que je ne pense pas que quiconque ait mentionné - avec un IDE personnalisé, vous pourriez en fait avoir un espace dur et un espace doux. Ils se ressembleraient (peut-être avec des nuances différentes dans l'IDE) .
D'ailleurs, vous pouvez le faire dès maintenant avec n'importe quelle langue - il suffit de basculer sur votre IDE pour que les traits de soulignement soient affichés sous forme d'espaces. Quiconque crée des plugins Eclipse pourrait probablement le faire en une heure .
Il est également possible de convertir de manière pragmatique le cas de chameau en "mots avec des espaces", votre IDE pourrait le faire pour vous mais ce serait légèrement plus étrange.