Hier ist ein Programmier- / Sprachproblem, über das ich gerne Ihre Gedanken hören würde.
Wir haben Konventionen entwickelt, die die meisten Programmierer befolgen sollten, die nicht Teil der Sprachsyntax sind, aber dazu dienen, den Code besser lesbar zu machen. Diese sind natürlich immer umstritten, aber es gibt zumindest einige Kernkonzepte, die den meisten Programmierern zusagen. Benennen Sie Ihre Variablen entsprechend, benennen Sie sie im Allgemeinen, machen Sie Ihre Zeilen nicht zu lang, vermeiden Sie lange Funktionen, Kapseln und dergleichen.
Es gibt jedoch ein Problem, zu dem ich noch keinen Kommentar gefunden habe, und das könnte das größte des ganzen Haufens sein. Es ist das Problem, dass Argumente beim Aufrufen einer Funktion anonym bleiben.
Funktionen stammen aus der Mathematik, in der f (x) eine eindeutige Bedeutung hat, weil eine Funktion eine viel strengere Definition hat als normalerweise beim Programmieren. Reine Funktionen in der Mathematik können viel weniger als sie in der Programmierung können und sie sind ein viel eleganteres Werkzeug, sie nehmen normalerweise nur ein Argument (normalerweise eine Zahl) und sie geben immer einen Wert (normalerweise auch eine Zahl) zurück. Wenn eine Funktion mehrere Argumente akzeptiert, handelt es sich fast immer nur um zusätzliche Dimensionen der Funktionsdomäne. Mit anderen Worten, ein Argument ist nicht wichtiger als die anderen. Sicher, sie sind explizit geordnet, aber ansonsten haben sie keine semantische Ordnung.
Bei der Programmierung haben wir jedoch mehr Freiheitsgrade bei der Definition von Funktionen, und in diesem Fall würde ich behaupten, dass dies keine gute Sache ist. In einer normalen Situation haben Sie eine Funktion wie diese definiert
func DrawRectangleClipped (rectToDraw, fillColor, clippingRect) {}
Betrachtet man die Definition, so ist bei korrekter Schreibweise der Funktion klar, was was ist. Wenn Sie die Funktion aufrufen, kann es sein, dass in Ihrer IDE / Ihrem Editor Intellisense- / Code-Vervollständigungsmagie vor sich geht, die Ihnen sagt, was das nächste Argument sein soll. Aber warte. Wenn ich das brauche, während ich den Anruf schreibe, fehlt hier nicht etwas? Die Person, die den Code liest, hat nicht den Vorteil einer IDE, und wenn sie nicht zur Definition springt, weiß sie nicht, welches der beiden als Argumente übergebenen Rechtecke wofür verwendet wird.
Das Problem geht noch weiter. Wenn unsere Argumente von einer lokalen Variablen stammen, kann es vorkommen, dass wir nicht einmal wissen, was das zweite Argument ist, da wir nur den Variablennamen sehen. Nehmen Sie zum Beispiel diese Codezeile
DrawRectangleClipped(deserializedArray[0], deserializedArray[1], deserializedArray[2])
Dies wird in unterschiedlichem Maße in verschiedenen Sprachen, aber auch in streng typisierten Sprachen, vermieden. Selbst wenn Sie Ihre Variablen vernünftig benennen, erwähnen Sie nicht einmal den Typ der Variablen, wenn Sie sie an die Funktion übergeben.
Wie bei der Programmierung üblich, gibt es viele mögliche Lösungen für dieses Problem. Viele sind bereits in gängigen Sprachen implementiert. Zum Beispiel benannte Parameter in C #. Alles, was ich weiß, hat jedoch erhebliche Nachteile. Die Benennung jedes Parameters bei jedem Funktionsaufruf kann möglicherweise nicht zu lesbarem Code führen. Es fühlt sich fast so an, als ob wir über die Möglichkeiten der Klartextprogrammierung hinauswachsen. Wir sind in fast allen Bereichen von NUR Text weggegangen, aber wir codieren immer noch das Gleiche. Weitere Informationen werden benötigt, um im Code angezeigt zu werden? Füge mehr Text hinzu. Wie auch immer, das wird ein bisschen tangential, also höre ich hier auf.
Eine Antwort, die ich auf das zweite Code-Snippet erhielt, war, dass Sie wahrscheinlich zuerst das Array in einige benannte Variablen entpacken und diese dann verwenden würden, aber der Variablenname kann viele Dinge bedeuten, und die Art und Weise, wie er aufgerufen wird, sagt Ihnen nicht unbedingt, wie er sein soll im Kontext der aufgerufenen Funktion interpretiert werden. Im lokalen Bereich haben Sie möglicherweise zwei Rechtecke mit den Namen leftRectangle und rightRectangle, da diese semantisch dargestellt werden, sie müssen jedoch nicht auf das erweitert werden, was sie darstellen, wenn sie einer Funktion zugewiesen werden.
Wenn Ihre Variablen im Kontext der aufgerufenen Funktion benannt werden, geben Sie weniger Informationen ein, als Sie mit diesem Funktionsaufruf möglicherweise könnten, und auf einer bestimmten Ebene führt dies zu einem schlechteren Code. Wenn Sie eine Prozedur haben, die ein Rechteck ergibt, das Sie in rectForClipping speichern, und dann eine andere Prozedur, die rectForDrawing bereitstellt, dann ist der eigentliche Aufruf von DrawRectangleClipped nur eine Zeremonie. Eine Zeile, die nichts Neues bedeutet und nur vorhanden ist, damit der Computer genau weiß, was Sie möchten, obwohl Sie dies bereits mit Ihrer Benennung erklärt haben. Das ist keine gute Sache.
Ich würde wirklich gerne neue Perspektiven dazu hören. Ich bin mir sicher, dass ich nicht der erste bin, der dies als Problem ansieht. Wie wird es also gelöst?