Nicht, dass ich gerade die bessere Idee hätte. Aber hast Du noch eine Idee, die Factory-Charakteristik von isIncludedIn besser im Namen darzustellen?
Leider nein. Ich bin fürchterlich schlecht darin Funktionen sinnvolle Namen zu geben. Ich versuche Prädikaten, also Funktionen, die schlussendlich boolsche Wert zurückgeben, mit Verben wie is
und has
zu prefixen. Das gibt zumindest etwas Auskunft über den Rückgabetypen, aber natürlich nicht über die erwarteten Parameter und deren Reihenfolge. Persönlich schreibe ich manchmal eine Pseudo-Typ-Annotation in Anlehnung an Haskells Typsprache als Kommentar an die Funktionen. Im Falle von isIncludedIn
zum Beispiel:
isIncludedIn :: Eq a => [a] -> a -> Bool
Der Kommentar gibt mir ein paar Auskünfte: Die Funktion erwartet als ersten Parameter eine Liste [a]
und als zweiten Parameter einen Wert vom Typ a
und liefert mir schlussendlich einen boolschen Wert. Außerdem soll da scheinbar etwas verlichen werden, das sagt mir die Vorbedingung Eq a
. Das hilft aber natürlich nur derjenigen, die mit dem Haskell-Typsystem vertraut ist, für alle anderen ist das nur Kauderwelsch. Das TypeScript Typ-System ist leider sehr langatmig und deshalb weniger geeignet, um diese Informationen zu transportieren.
Ich habe dann gerade mal auf Hoogle, einer Suchmaschine für Haskell-Funktionen, nach diesem Typen gesucht und da werden unter anderem folgende Namen vorgeschlagen:
has
hasElem
elem
∋
Also da ist auch nichts Brauchbares bei. Es scheint etwas dran zu sein, an dem Zitat:
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.