it-swarm-eu.dev

Ist es ein schlechtes Design für eine Programmiersprache, Leerzeichen in Bezeichnern zuzulassen?

Einige ( Link 1 , Link 2 ) Programmiersprachen erlauben Leerzeichen in ihren Bezeichnern (z. B. Variablen, Prozeduren), aber die meisten von ihnen verwenden keine und stattdessen verwenden Programmierer normalerweise Kamelfall , Schlangenfall und andere Möglichkeiten, Wörter in Namen zu trennen.

Um Leerzeichen oder sogar andere Unicode-Zeichen zu unterstützen, erlauben einige Programmiersprachen die Kapselung des Namens mit einem bestimmten Zeichen, um dessen Anfang und Ende abzugrenzen.

Ist es eine schlechte Idee, Leerzeichen zuzulassen, oder ist es aus historischen Gründen im Allgemeinen nicht zulässig (wenn es mehr Einschränkungen gab als jetzt oder einfach entschieden wurde, dass es sich nicht lohnt, sie umzusetzen)?

Die Frage betrifft eher die wichtigsten Vor- und Nachteile der Implementierung in neu erstellten Programmiersprachen.

Verwandte Seiten: Link 1 , Link 2 .

51
user7393973

Folgendes berücksichtigen.

 var [Example Number] = 5;
 [Example Number] = [Example Number] + 5;
 print([Example Number]);

 int[] [Examples Array] = new int[25];
 [Examples Array][[Example Number]] = [Example Number]

Vergleichen Sie es mit dem traditionelleren Beispiel:

 var ExampleNumber = 5;
 ExampleNumber = ExampleNumber + 5;
 print(ExampleNumber);

 int[] ExamplesArray = new int[25];
 ExamplesArray[ExampleNumber] = ExampleNumber;

Ich bin mir ziemlich sicher, dass Sie bemerkt haben, dass die Belastung für Ihr Gehirn, das zweite Beispiel zu lesen, viel geringer war.

Wenn Sie Leerzeichen für einen Bezeichner zulassen, müssen Sie ein anderes Sprachelement einfügen, um den Anfang und den Stopp eines Wortes zu markieren. Diese Begrenzer zwingen das Gehirn zu zusätzlichen Analysen und erzeugen, je nachdem, welches Sie auswählen, eine Reihe neuer Mehrdeutigkeitsprobleme für das menschliche Gehirn.

Wenn Sie keine Trennzeichen einfügen und versuchen zu schließen, über welche Kennung Sie sprechen, wenn Sie Code nur nach Kontext eingeben, laden Sie eine andere Art von Dose Würmer ein:

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

Perfekt machbar.

Ein totaler Schmerz für die Musterübereinstimmung Ihres Gehirns.

Das Lesen dieser Beispiele ist nicht nur wegen der Auswahl der Wörter, die ich auswähle, schmerzhaft, sondern auch, weil Ihr Gehirn einige zusätzliche Zeit benötigt, um zu identifizieren, was jeder Identifikator ist.

Betrachten Sie noch einmal das regulärere Format:

 var Example = 5;
 var Number = 10;
 var ExampleNumber = Example + Number;

 int[] ExamplesArray = new int[25];
 ExamplesArray[ExampleNumber] = ExampleNumber;

 ExampleNumber = ExampleNumber + Example + Number;
 printText(ExampleNumber);

Merkst du etwas

Die Namen der Variablen sind immer noch schrecklich, aber die Anstrengung, sie zu lesen, ging weit zurück. Dies geschieht, weil Ihr Gehirn jetzt einen natürlichen Anker hat, um den Anfang und das Ende jedes Wortes zu identifizieren, sodass Sie diesen Teil Ihres Denkens abstrahieren können. Sie müssen sich nicht mehr um diesen Kontext kümmern - Sie sehen einen Bruch im Text, Sie wissen, dass es sich um eine neue Kennung handelt.

Wenn Sie Code lesen, hat Ihr Gehirn nicht viel lesen die Wörter so viel wie es passt es mit dem, was Sie gerade im Kopf haben. Sie hören nicht wirklich auf, "ExampleWord" zu lesen. Sie sehen, dass die Gesamtform des Dings, ExxxxxxWxxd, mit allem übereinstimmt, was Sie in Ihrem mentalen Haufen versteckt haben, und sie lesen weiter. Deshalb ist es leicht, Fehler wie "ExampleWord = ExapmleWord" zu übersehen - Ihr Gehirn liest sie nicht wirklich. Sie passen nur ähnliche Sachen zusammen.

Betrachten Sie noch einmal Folgendes:

 Example Word += Example  Word + 1;

Stellen Sie sich nun vor, Sie versuchen, diesen Code zu debuggen. Stellen Sie sich vor, wie oft Sie diesen zusätzlichen Platz in "Beispielwort" verpassen. Ein falsch platzierter Brief ist bereits auf den ersten Blick schwer zu erkennen. Ein zusätzlicher Raum ist um eine Größenordnung schlechter.

Am Ende ist es schwer zu sagen, dass das Zulassen von Leerzeichen den Text mehr Lesbar machen würde. Es fällt mir schwer zu glauben, dass der zusätzliche Aufwand an zusätzlichen Terminatoren und der zusätzliche Aufwand für mein Gehirn es wert wären, diese Art von Funktionalität zu verwenden, wenn die Sprache, mit der ich arbeite, sie hätte.

Persönlich halte ich es für schlechtes Design - nicht wegen des Aufwandes für den Compiler, den Interpreter oder was auch immer, sondern weil mein Gehirn in diesen Räumen stolpert und denkt, dass es sich um eine neue Kennung handelt, die im Begriff ist beginnen, wenn es nicht ist.

In gewissem Sinne leidet unser Gehirn unter den gleichen Problemen wie unsere Prozessoren, wenn es um Verzweigungsvorhersage geht.

Seien Sie also bitte freundlich zu unseren Gedankengängen. Setzen Sie keine Leerzeichen auf Ihre Kennungen.

101
T. Sar

Ist es ein schlechtes Design für eine Programmiersprache, Leerzeichen in Bezeichnern zuzulassen?

Kurze Antwort :

Könnte sein.

Etwas längere Antwort :

Design ist der Prozess, bei dem widersprüchliche Lösungen für komplexe Probleme identifiziert und gewichtet werden und gute Kompromisse eingegangen werden, die den Anforderungen der Stakeholder entsprechen. Es gibt kein "schlechtes Design" oder "gutes Design" außer im Kontext der Ziele dieser Stakeholder , und Sie haben nicht gesagt, was diese Ziele sind Die Frage ist also zu vage, um sie zu beantworten.

Noch längere Antwort :

Wie ich oben angedeutet habe, hängt es von den Zielen des Wahlkreises ab, die der Sprachdesigner anspricht. Betrachten wir zwei Sprachen, die ich kenne: die für Menschen lesbare Form von MSIL, die einfache "Zwischensprache", in die C # kompiliert wird, und C #.

C # soll eine Sprache sein, die Branchenentwickler in Umgebungen, die Microsoft als strategisch wichtig erachtet, hochproduktiv macht. In C # ist ein Bezeichner eine Folge von einem oder mehreren UTF-16-Zeichen, wobei alle Zeichen als alphanumerisch oder _ Klassifiziert sind. und das erste Zeichen ist keine Zahl.

Diese lexikalische Grammatik wurde sorgfältig ausgewählt, um Eigenschaften zu haben, die den Anforderungen dieser strategisch wichtigen LOB-Entwickler entsprechen:

  • Es ist eindeutig als Bezeichner lexibel; 1e10 Muss beispielsweise keine legale Kennung sein, da sie mit einem Double lexikalisch nicht eindeutig ist.
  • Es unterstützt Redewendungen, die in C, C++ und Java häufig verwendet werden, z. B. die Benennung eines privaten Felds _foo. C # wurde entwickelt, um Entwickler anzusprechen, die bereits eine gemeinsame LOB-Sprache beherrschten.
  • Es unterstützt Bezeichner, die in fast jeder menschlichen Sprache geschrieben sind. Wenn Sie var φωτογραφία = @"C:\Photos"; In C # schreiben möchten, fahren Sie fort. Dies macht die Sprache für Entwickler zugänglicher, die nicht Englisch als Muttersprache haben.

C # unterstützt jedoch keine Leerzeichen in Bezeichnern.

  • Dies würde die lexikalische Grammatik komplizieren und Mehrdeutigkeiten einführen, die dann gelöst werden müssen.
  • In den allermeisten Interop-Situationen ist dies nicht erforderlich. Niemand nennt seine öffentlichen Mitglieder, um Leerzeichen in ihnen zu haben.

Es war eine gute Idee, andere Zeichen als Buchstaben und Zahlen in C # -Kennungen nicht zuzulassen.

Im Gegensatz dazu können Sie in MSIL eine Funktion fast alles benennen, einschließlich Leerzeichen oder anderer "seltsamer" Zeichen in Methodennamen. Und tatsächlich nutzt der C # -Compiler dies! Es werden "unaussprechliche Namen" für vom Compiler generierte Methoden generiert, die nicht direkt vom Benutzercode aufgerufen werden dürfen.

Warum ist dies eine gute Idee für MSIL und nicht für C #? Weil die MSIL-Anwendungsfälle völlig unterschiedlich sind:

  • MSIL ist nicht als primäre Entwicklungssprache konzipiert. Da es sich um eine Zwischensprache handelt, ist der Hauptanwendungsfall für Compilerentwickler, die versuchen, die Ausgabe ihres Compilers zu verstehen.
  • MSIL ist so konzipiert, dass es mit jeder älteren Microsoft-Entwicklungsumgebung einschließlich pre-.NET Visual Basic und anderen OLE) zusammenarbeiten kann = Automatisierungsclients, die Leerzeichen in Bezeichnern zulassen.
  • Wie oben erwähnt, ist die Möglichkeit, einen "unaussprechlichen" Namen für eine Funktion zu generieren, eine Funktion und kein Fehler.

Ist es also eine gute Idee, Leerzeichen in Bezeichnern zuzulassen? Es hängt von den Anwendungsfällen der Sprache ab. Wenn Sie einen soliden Anwendungsfall haben, um dies zuzulassen, lassen Sie es auf jeden Fall zu. Wenn Sie dies nicht tun, tun Sie es nicht.

Weiterführende Literatur : Wenn Sie ein Beispiel für eine faszinierende Sprache suchen, in der komplexe Bezeichner hervorragend verwendet werden, lesen Sie Inform7 , ein DSL für textbasierte Abenteuerspiele:

The Open Plain is a room. 
"A wide-open grassy expanse, from which you could really go any way at all."

Dies deklariert ein neues Objekt vom Typ room mit dem Namen The Open Plain, Und dieses Objekt kann dann im gesamten Programm als solches bezeichnet werden. Inform7 hat einen sehr umfangreichen und komplexen Parser, wie Sie sich vorstellen können.

Hier ist ein komplexeres Beispiel:

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.

Beachten Sie, dass way und next location Und further place Und reverse Bezeichner in dieser Sprache sind. Beachten Sie auch, dass next location Und the next location Aliasing sind. (Übung : Was macht dieser Code mit der Datenstruktur, die die Karte der Räume im Spiel verwaltet?)

Inform7 hat einen Wahlkreis, der eine vollständig natürlich wirkende englische Sprache als Quellcode verwenden möchte. Es erscheint seltsam, dieses Inform7 als zu schreiben

  change the way exit of the location to the_next_location;

Es ist eintauchend, dies zu tun. Vergleichen Sie dies mit der (ausgezeichneten) Antwort von T. Sar, die den Kontrastpunkt darstellt - dass es für Entwickler in LOB-Sprachen eintauchend ist, zu versuchen, mental herauszufinden, wo sich die Bezeichner befinden. Wieder es kommt auf den Kontext und die Ziele an.

59
Eric Lippert

Ein relativ bekanntes Beispiel ist ein Fortran-Code, bei dem ein einzelner Tippfehler die Bedeutung des Codes vollständig geändert hat.

Es war beabsichtigt, einen Codeabschnitt 100 Mal zu wiederholen (mit I als Schleifenzähler):

DO 10 I = 1,100

Das Komma wurde jedoch als Punkt falsch eingegeben:

DO 10 I = 1.100

Da Fortran Leerzeichen in Bezeichnern zulässt (und automatisch Variablen erstellt, wenn diese nicht deklariert wurden), ist die zweite Zeile vollkommen gültig: Es wird implizit eine falsche reale Variable namens DO10I erstellt und ihr die Nummer 1.1 zugewiesen. Das Programm wurde also fehlerfrei kompiliert. Die Schleife konnte einfach nicht ausgeführt werden.

Der fragliche Code kontrollierte eine Rakete; Wie Sie sich vorstellen können, hätte ein solcher Fehler katastrophal sein können! Glücklicherweise wurde in diesem Fall der Fehler beim Testen festgestellt und es wurden keine Raumfahrzeuge beschädigt.

Ich denke, dies zeigt ziemlich gut eine der Gefahren, wenn Leerzeichen in Bezeichnern zugelassen werden…

15
gidds

Ist es ein schlechtes Design für eine Programmiersprache, Leerzeichen in Bezeichnern zuzulassen?

Sie haben wichtige Implementierungsdetails vergessen:

Was ist Quellcode für Sie?

Ich mag die Definition von [~ # ~] fsf [~ # ~] : die bevorzugte Form, an der Entwickler arbeiten. Es ist eine soziale Definition, keine technische.

In einigen Sprachen und ihrer Implementierung in den 1980er Jahren (denken Sie an Original Smalltalk und 1980 Smalltalk-Maschinen) war der Quellcode keine Folge von Zeichen. Es war ein abstrakter Syntaxbaum und wurde vom Benutzer mit Maus und Tastatur unter Verwendung einer GUI manipuliert.

In gewissem Sinne akzeptiert Common LISP Leerzeichen in seinen Symbolen.

Sie könnten sich entscheiden (das ist ein Los Arbeit), beide Programmiersprachen ( dokumentiert in einem Bericht mit beiden ) gemeinsam zu gestalten Syntax und Semantik ), ihre Implementierung (wie einige Software) und ihr Editor oder [~ # ~] ide [~ # ~] (wie einige Software).

Lesen Sie alte Diskussionen auf tunes.org . Lesen Sie die alte Arbeit bei INRIA weiter

@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}
}

und

@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},
}

Siehe auch meine Bismon-Berichtsentwurf und http: //refpersys.org/

Mein RefPerSys-Traum ist es, eine solche deklarative Programmiersprache gemeinsam mit einem Nice IDE dafür zu entwerfen. Ich weiß, dass es ein Jahrzehnt dauern kann. Denken Sie, wir sind in gewissem Sinne verrückt wir sind!

Unter dem Gesichtspunkt der Benutzerfreundlichkeit sind Syntaxfärbung und Autocompletion wichtiger als Leerzeichen in Bezeichnern (siehe beide GtkSourceView und CodeMirror zur Inspiration). Optisch ein Unterstrich _ sieht einem Leerzeichen nahe. Und wenn Sie Ihre eigene IDE codieren, können Sie dies akzeptieren ctrlspace als Eingabe für "Leerzeichen innerhalb von Namen". Meiner Meinung nach sollten ℕ und ∀ "Schlüsselwörter" sein, die Frage wird, wie Sie sie eingeben. Ich träume vom Tippen (inspiriert von LaTeX) \forallESC um ein ∀ zu bekommen (und ich habe von einigen emacs Submodi dafür gehört).

NB: Ich hasse Python (und Makefile - s), weil Leerzeichen (oder Tabulatoren) dort von Bedeutung sind.

Es ist nicht von Natur aus schlechtes Design, erlauben Leerzeichen in Symbolnamen. Dies kann anhand eines einfachen Gegenbeispiels gezeigt werden.

Kotlin erlaubt Leerzeichen in Namen. Es gibt auch offizielle Codierungskonventionen, die angeben wenn es in Ordnung ist, diese Funktion zu verwenden :

Namen für Testmethoden

In Tests (und nur in Tests) ist es akzeptabel, Methodennamen mit Leerzeichen in Backticks zu verwenden.

Beispiel:

class MyTestCase {
     @Test fun `ensure everything works`() { /*...*/ }

"Gut" und "schlecht" ist natürlich subjektiv, aber die Verwendung von Leerzeichen in Testmethodennamen macht das Lesen des Testcodes viel angenehmer und auch die Testergebnisse Schön zu lesen, ohne dass sich der Testcodierer mit einem hässlichen Methodennamen und wiederholen muss eine vom Menschen lesbare Testbeschreibung separat.

Der wichtige Punkt hierbei ist, dass diese Methoden normalerweise nicht explizit aus von Menschen geschriebenem Code aufgerufen werden. Daher befindet sich bei der Methodendefinition nur die Stelle, an der der Name erscheint. Ich denke, dies ist eine wichtige Unterscheidung, um zu überlegen, wann Leerzeichen in Symbolnamen eine gute Idee sein könnten: Nur wenn das Symbol vom Programmierer nur einmal geschrieben wird.

6
hyde

Faustregel:

Fehler sind proportional zu der Zeit, die zum lauten Vorlesen von Code benötigt wird.

Alles, was die Anzahl der offenen Klammern, der geschlossenen Klammern, der offenen geschweiften Klammer, der geschlossenen geschweiften Klammer, der offenen Klammer, der geschlossenen Klammer ... erhöht, erhöht die Anzahl der Fehler im Code.

Dies ist ein Grund, warum * Stern oder Splat und kein Sternchen ist. # ist shhh! ist Knall. Ich vermute, Mathematiker haben auch kurze verbale Ausdrücke für ihre Symbole.

Deshalb füllen sich Technologiefelder mit Akronymen und Abkürzungen: Wir denken in Worten. Wir haben eine begrenzte Aufmerksamkeitsspanne und können nur so viele Symbole in unserem Kopf halten. Also gruppieren und fassen wir die Dinge zusammen.

ReallyReallyLongIdentifier kann dasselbe tun. Dort besteht der Kompromiss zwischen dem Erinnern an das, wofür es ist, und dem Verwickeln in unsere Denkprozesse. Aber ReallyReallyLongIndentifer ist immer noch besser als QzslkjfZslk19

Je weiter es von seiner Kreation entfernt ist, desto mehr muss es unvergesslich sein. Daher werden i, j, k für Schleifenkonstrukte verwendet - wie Eintagsfliegen leben sie für die Lebensdauer einer Schleife, und diese Schleife beginnt und endet auf demselben Bildschirm.

Dies gilt auch für die Codierung:

A = FunctionAlpha (21, $ C, $ Q)

B = FunctionBeta ($ A, $ D, $ R)

ist sauberer als

B = FunctionBeta (FunctionAlpha (21, $ C, $ Q), $ D, $ R)

Ich denke, dies ist ein Grund, warum Tabellenkalkulationen so miserable Fehlerraten aufweisen: Außer durch Hinzufügen temporärer Zellen/Zeilen/Spalten gibt es keine Möglichkeit, unordentliche verschachtelte Anweisungen zu vermeiden.

3

Ich habe lange gebraucht, um wirklich zu verstehen, dass es nie wirklich eine beste Sprache geben wird. Für ein Programmierteam sind die wichtigsten Aspekte, dass die Sprache bekannt ist, von vielen Tools unterstützt wird, eine minimale Sprachsyntax aufweist und Sie so selten wie möglich überrascht.

Für einen einzelnen Codierer ist eine leistungsstarke Sprache, die schnelle Test-/Ausführungszyklen ermöglicht, großartig.

Für einen Administrator ist eine Sprache wichtig, die auf die Shell-Sprache des Betriebssystems zugeschnitten ist.

Für einige Arbeitssprachen, die von verschiedenen Disziplinen gemeinsam genutzt werden, können DSLs nett sein.

Gibt es einen Platz für eine Sprache mit Leerzeichen - wahrscheinlich. Es verstößt gegen die nicht überraschenden Regeln, passt aber sehr gut zu den DSL-Zielen.

Eine Sache, von der ich glaube, dass sie niemand erwähnt hat - mit einem benutzerdefinierten IDE könnten Sie tatsächlich einen harten und einen weichen Raum haben. Sie würden ähnlich aussehen (vielleicht haben sie unterschiedliche Schattierungen in der IDE) .

Im Übrigen können Sie dies jetzt mit jeder Sprache tun - setzen Sie einfach einen Schalter auf Ihre IDE, um Unterstriche als Leerzeichen anzuzeigen. Jeder, der Eclipse-Plugins erstellt, könnte dies wahrscheinlich in einer Stunde tun .

Es ist auch möglich, Kamelbuchstaben pragmatisch in "Wörter mit Leerzeichen" umzuwandeln. Ihr IDE könnte das für Sie tun, aber es wäre etwas seltsamer.

0
Bill K