it-swarm.com.de

Was ist aus Sicht der Benutzerfreundlichkeit mit der Syntax im C-Stil falsch?

Vorläufer: Dies ist eine Frage zu UX, nicht zur technischen Implementierung.

Kontext. Ich möchte eine kleine Sprache mit einer Textsyntax entwerfen. Es wird von Business Analysten verwendet, um Systemanforderungen zu definieren - also technisch bewusst, aber nicht tiefgreifend.

Vor dem Hintergrund der Programmierung bin ich seit so vielen Jahren in die C-Syntax vertieft, dass ich sie nicht objektiv betrachten kann. Im Vergleich zu dem heute in anderen Kontexten (HTML, XML) vorherrschenden SGML-Stil betrachte ich den C-Stil als Modell der Klarheit. Ich habe jedoch verschiedene Kommentare an verschiedenen Stellen gesehen, die auf Mängel hinweisen. Ich weiß, dass es praktische Probleme geben kann (z. B. Determinismus beim Parsen), aber das interessiert mich hier nicht.

Insbesondere möchte ich alle Usability-Mängel des C-Stils verstehen. Mit "C-Stil" meine ich die durch geschweifte Klammern getrennten Blöcke, Parameter in Klammern usw. der C-Sprache.

Vorschläge/Verweise auf Artikel/Artikel, die Probleme und (vorzugsweise) alternative Lösungen beschreiben, sind sehr willkommen.

Vielen Dank.

6
sfinnie

Was Sie erstellen möchten, ist eine domänenspezifische Sprache . Das Grundprinzip dieser Art von (Programmier-) Sprache lautet: Halten Sie die Syntax so einfach wie möglich, während sich einfach auf "vom Menschen lesbar" bezieht, indem Sie alle nicht benötigten Funktionen entfernen.

Schwierigkeiten der C-Syntax

Was macht C-Syntax schwer zu schreiben:

  • Fehlendes Nachlaufen; Ich habe viele Anfänger gesehen, die auf diesem Fluch waren.
  • Fehlend} oder).
  • Das Konzept der Zeiger (Sie werden diesen wahrscheinlich nicht brauchen)
  • Variable Bereiche
  • copy-by-Value vs. Referenzen

Wenn Sie eine kleine Teilmenge der Sprachfunktionen verwenden, ist der Code sowohl leichter zu lesen als auch zu schreiben (sofern er konsistent ist).

Beispiel

Angenommen, der Code muss ausdrücken, dass Prozess A von Prozess B abhängig ist.

Process A = "Cook something";
Process B = "Go shopping.";
depends_on(A, B);

oder:

Cook something <- Go shopping

Im zweiten Beispiel muss der "Codierer" nicht einmal das Konzept der Parameter kennen!

Technische Komplexität beeinflusst die Benutzerfreundlichkeit

Was am Ende mindestens genauso wichtig sein kann: eine anständige Kompilierungs-/Debugging-Umgebung, Fehlermeldungen, die zur Lösung des eigentlichen Problems beitragen usw. Aufgrund der technischen Schwierigkeiten beim Parsen von C gibt der Compiler häufig nur schwache Fehler aus im Zusammenhang mit der wahren Ursache. Auch hier hilft eine einfache Syntax.

4
giraff

Eines der Probleme mit der Syntax im C-Stil besteht darin, dass es nicht einfach ist (ohne einen anständigen Editor) herauszufinden, welche} oder) mit welchen gepaart sind. Aus Gründen der Übersichtlichkeit benötigen Sie daher Leerzeichen. (Ein Problem, das in LISP, das die Leute viele irritierende alberne Klammern genannt haben, noch deutlicher wurde). EIN </body> tag ist viel klarer: es beendet das <body>.

Für einen historischen Überblick über Programmiersprachen und die eingeführten Konzepte (und warum) würde ich Robert W. Sebestas Buch 'Konzepte von Programmiersprachen' empfehlen. Es enthält die früheren Programmiersprachen und erklärt, warum sie sich zu dem entwickelt haben, was wir jetzt wissen.

3
Marielle

Andere haben die Schwierigkeiten in der C-Syntax erwähnt, zu denen ich nur hinzufügen kann:

  • Der Operator * in Deklarationen (fügt Verwirrung mit der Multiplikation hinzu nd hat seltsame Vorrangregeln, die zu Kuriositäten wie int * foo, bar, dem Deklarieren eines Zeigers und einer direkten Variablen und der WTF, der Funktionszeigersyntax, führen Ganz zu schweigen davon: Warum haben sie nicht einfach eine längere Syntax wie "address of foo" usw. verwendet?.

  • Die spärliche Benennung von Bezeichnern und Befehlen in der Standardbibliothek anstelle einer moderneren, ausführlicheren und lesbareren Syntax.

  • Die seltsamen Regeln für die Typförderung (char -> int, float -> double)

  • Die seltsame Art, den Datentyp einer Zahl anzugeben (1ULL usw.).

  • Die inkonsistente Art und Weise, in der Arrays in einigen Deklarationen Zeiger sind und in anderen nicht.

  • Die inkonsistente Art und Weise, wie sizeof () wie eine Funktion aussieht, ist ein Operator und gibt manchmal die Größe der Zeigervariablen und manchmal die tatsächliche Größe eines Arrays zurück, jedoch nur, wenn es sich um eine lokale Variable handelt. OK, das kommt in die Semantik.

  • Die for-Schleife. Ich habe es nach jahrzehntelangem Codieren in C auswendig gelernt, aber ist das die willkürlichste und verwirrendste Syntax oder was? Semikolons innen ein Befehl?

  • Der Kommaoperator. Nicht nur ein Parametertrennzeichen, sondern auch eine Möglichkeit, mehrere Ausdrücke miteinander zu verknüpfen, sondern nur den letzten zurückzugeben. Und wenn Sie eine Tastatur haben, die hat; und auf demselben Schlüssel (wie Deutsch) eine sehr häufige Quelle für Tippfehler. Denken Sie int foo = 13, gSomething = 14; wo du schreiben wolltest int foo = 13; gSomething = 14;

Sie haben nach alternativen Lösungen gefragt:

Ich würde vorschlagen, dass Sie sich englischsprachige Programmiersprachen wie Inform 7, LiveCode (und dessen Vorgänger HyperTalk) sowie AppleScript ansehen. Das zugrunde liegende Modell von AppleScript (mit Datentypen, die Sie einhalten müssen, aber nicht deklarieren können) ist zwar zu technisch, aber die Art und Weise, wie die Syntax in Freiform definiert wird, sorgt für sehr lesbaren Code.

Im Wesentlichen können Sie nur englische Sätze aus einer kleinen Teilmenge des Englischen schreiben. Dies bedeutet, dass es nicht jeden englischen Satz versteht, aber sobald Sie ein Skript sehen, ist sofort klar, was es tut, und es lädt zum Kopieren und Einfügen ein, wobei Sie Code sehen, der fast das tut, was Sie wollen, und ihn einfach ändern .

AppleScript hatte auch eine "Aufnahme" -Funktion, in der Sie etwas tun konnten, und sein Editor schrieb das entsprechende Skript auf, das Sie wiederum selbst durch Ausprobieren leicht ändern konnten.

Halten Sie sich jedoch in jedem Fall an einfache Konstrukte und lassen Sie "clevere" Konstrukte wie Verkettungszuweisungen wie x = y = 4 weg; Sie werden im besten Fall Nicht-Geeks verwirren, im schlimmsten Fall unbeabsichtigte Tippfehler kompilieren lassen.

Wenn Sie etwas Leichtes wollen und nicht verheiratet mit der Verwendung von Text sind, sehen Sie sich eine Benutzeroberfläche an, wie Sie sie in Apples Automator oder in der Programmiersprache Scratch sehen können. Sie können es hinter den Kulissen in einer Textform speichern. Wenn Sie jedoch eine Benutzeroberfläche zum Erstellen der Ausdrücke haben und der Benutzer die allgemeinen Befehle direkt aus der Dokumentation oder einem Fenster voller Snippets ziehen und ablegen kann, ist dies viel einfacher Lernen Sie für den Gelegenheitskodierer, der vielleicht dreimal im Jahr codiert und den Rest der Zeit einen anderen Job hat.

2
uliwitness