Und warum heißt diese API jetzt so?

Abstaktion im Programmcode bedeutet auch, dass man sich die richtigen Namen, meist Überbegriffe zu einer Materie suchen muss.

Und weil uns einst ein alter Bekannter die Zeilen:

Schon gut! Nur muss man sich nicht allzu ängstlich quälen;
Denn eben wo Begriffe fehlen,
Da stellt ein Wort zur rechten Zeit sich ein.
Mit Worten läßt sich trefflich streiten,
Mit Worten ein System bereiten,
An Worte läßt sich trefflich glauben,
Von einem Wort läßt sich kein Jota rauben.

hinterließ, möchte ich mal etwas darüber “klagen”, wie schwer es am Anfang ist, das richtige Wort zum richtigen Begriff zu finden.

Bei meiner ersten XML Implementierung suchte ich nach einem “Begriff” für ein Teilobjekt eines “geteilten” Strings bezeichnen sollte. Im heutigem C++ Standard wäre das ein std::stringview, doch den gab es damals noch nicht.

“Fragment” wäre meine Idee dazu gewesen, doch das klang mir zu seltsam und fast negativ (wegen Bruchstück -> zerbrechen -> Gewalt).

In einem Gespräch erklärte ich mein Dilemma einer Nicht-Programmier-Kollegin die prompt meinte:

Ich weiß was du meinst. Der Begriff den du suchst ist “Idol”

Darauf dachte ich mir:
“Woho, ich mich muss mich wohl sehr undeutlich ausgedrückt haben.”

Um das Rätsel zu lösen: Das Wort, das mir partout nicht einfallen wollte war Token. Ein Blick über die Standard-C-Funktionen hätte gereicht: strtok().

Tja, aber das Problem mit den richtigen und vor allem intuitiven Begriffen folgte nicht nur mir, sondern wohl auch vielen anderen Programmierern.
Bei mir liegt es wahrscheinlich an meinem schlechten Englisch, dass ich dann in den falschen Wörtern auch Kandidaten für APIs und Funktionsnamen finde.

Und analog zum Beitrag mit den Symbolen gibt es auch das Problem, dass manche Begriffe im Laufe der Zeit durch neue Technlogien sinnfreier werden.

Mein Lieblingsbeispiel ist “Disk” als Begriff für alles, worauf man physisch Daten speichern kann. Heute werden auch USB Sticks über mit “Disk” benannte APIs angesteuert, obwohl da nichts Rundes oder Drehendes mehr dran ist.
Ich würde daher heute den Überbegriff “Storage” für solche Funktionen wählen, doch nachdem niemand alle APIs aller Betriebssystem umstellen will, bleibt es wohl vorerst bei “Disk”.

Ein anderer Begriff in der Grafik ist z.B. “Surface” als Oberfläche um darauf zu zeichnen. Dieses Wortbild ist an 2D Grafik und Bildschirme wie auch Drucker angepasst. Aber im Sinne von 3D-Druck und Holographie machen “Surface” Objekte etwas wenig Sinn.
Ich könnte mich mit “Area” im Sinne einer “GraphicsArea” gut anfreunden … aber ob das andere auch so sehen?

Ich stehe aktuell im GATE Projekt ebenso vor einigen Entscheidungen, wie APIs heißen sollen. Und das sind Entscheidungen, die man möglichst nicht alle paar Monate ändern sollte, weil das Unmengen an Anpassungen zur Folge hätte.

Gleichzeitig soll jeder Name zwar abstrakt sein, damit technische Änderungen den Begriff nicht ad absurdum führen, parallel dazu will man aber auch keine komplizierten neuen Wörter einführen, die keiner kennt und dann keinen nutzt bzw. finden kann.

Fazit: Codes lesen hilft

Ich habe noch kein Buch mit Auflistungen von “coolen” Begriffen gefunden, die sich perfekt in APIs, Struktur- und Funktionsnamen abbilden lassen.

Doch es gibt eine riesige Anzahl an Entwicklern da draußen, die alle auf ihren Gebieten gute Ideen haben.
Und so brachte mich das Lesen von vielen Quellcodes um ein ordnentliches Stück weiter.

Man findet dort teils echt geniale und konkret beschreibende Begriffe in APIs, aber auch Gegenbeispiele, wie man es nicht machen sollte.


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!