10

In der funktionalen Programmierung ist es oft wichtig, jeden "Schleifen" -Code so zu optimieren, dass er tail-rekursiv ist. Tail-rekursive Algorithmen werden normalerweise zwischen zwei Funktionen aufgeteilt, von denen eine den Basisfall und die andere die eigentliche Schleife implementiert. Ein gutes (wenn auch akademisches) Beispiel wäre die umgekehrte Funktion.Wie lautet Ihre Namenskonvention für Hilfsfunktionen?

reverse :: [a] -> [a] 
reverse = reverse_helper [] 

reverse_helper :: [a] -> [a] -> [a] 
reverse_helper result [] = result 
reverse_helper result (x:xs) = reverse_helper (x:result) xs 

"reverse_helper" ist nicht wirklich ein guter, beschreibender Name. "Reverse_rekursive_part" ist jedoch nur peinlich.

Welche Namenskonvention würden Sie für Hilfsfunktionen wie diese verwenden?

+0

Welche Sprache ist das? –

+0

Es tut mir leid. Ich arbeite gerade an einem Haskell-Projekt, das diese Frage inspiriert hat. Ich hätte vielleicht ein Python/Java-Beispiel geben können, obwohl solche Hilfsfunktionen in Imperativsprachen nicht so nützlich sind. – Cybis

Antwort

3

Ich neige dazu, "_recurse" bis zum Ende hinzuzufügen. Also "reverse_recurse". Ich weiß nicht, woher ich das habe. Ich mag es, die Base-Case-Funktion so einfach zu lassen, wie Sie es in Ihrem Beispiel getan haben. Es ist eher die "öffentliche" Funktion und die Tatsache, dass es eine Hilfsfunktion verwendet, um die Iteration durchzuführen, ist für den Aufrufer irrelevant. In Javascript gehe ich manchmal so weit, dass ich die iterative Funktion durch eine Schließung verberge, um deutlich zu machen, dass sie nicht direkt aufgerufen werden soll.

+0

"_recurse" - das ist ein guter. – Cybis

1

Setup und führen

Beispiel:

function whateverSetup() { ... } 
function whateverExecute() { ... } 
+2

whereverySetup ist ein schrecklicher Name, wenn die Funktion öffentlich ist. – Cybis

+0

@ [Cybis]: Es sollte impliziert werden, dass Sie "was auch immer" durch einen geeigneten beschreibenden Begriff ersetzen, z. WidgetSetup, WidgetExecute, etc. –

+0

Steven: Ich denke, sein Punkt war, dass "Setup" kein nettes Suffix für exportierte Funktionen ist. – Bladt

5

Ich verwende immer do_, wie "do_compute" mit "compute". Ich finde es ziemlich beschreibend, da es effektiv der Teil der Funktion ist, der die Aktion ausführt, während die "Compute", die aufgerufen wird, einen einfachen beschreibenden Namen für die Außenwelt haben muss.

21

Sie können die Hilfsfunktion beliebig aufrufen, und es spielt keine Rolle, solange Sie die Hilfsfunktion nicht in den globalen Namespace stellen. Einfach eine "Prime" hinzufügen, scheint eine gängige Praxis. :) zB in Haskell,

reverse :: [a] -> [a] 
reverse = reverse' [] 
    where reverse' :: [a] -> [a] -> [a] 
      reverse' result [] = result 
      reverse' result (x:xs) = reverse' (x:result) xs 
5

ich mit ShreevatsaR zustimmen, wenn Sie auf oberste Ebene nicht die Helferfunktion machen (oder noch schlimmer, stecken es in der Exportliste), als es nicht das, was ist egal sein Name ist. Ich nenne die Hilfsfunktionen f und g.

reverse :: [a] -> [a] 
reverse = f [] 
    where 
    f ys []  = xs 
    f ys (x:xs) = f (x:ys) xs 

Ich verwende nur dieses Namensschema für kleine Funktionen (sonst weiß ich nicht, was die f bezeichnet). Warum würden Sie jemals wieder große Funktionen schreiben?

Allerdings, wenn Sie Ihre ‚Helfer‘ wollen Funktion exportieren, weil es für andere nützlich sein könnte, würde ich es nennen:

reverseAccumulator 

Wie Haskells zip und zipWith. Aber ich würde diese "Helfer" -Funktionen nicht nennen, zipWith ist nur eine generische Funktion und zip ist die Standardimplementierung (wahrscheinlich diejenige, die am meisten benutzt wird).

+0

Ich mag die Verwendung von Prime (rev -> rev '= wie ShreevatsaR andeutet, aber ich denke, das sollte die akzeptierte Antwort sein aufgrund ihrer Allgemeinheit und weil sie sich auf Konventionen in den Bibliotheken bezieht. – Bladt

2

Ich verwende aux oder foo_aux (für Hauptfunktion foo), und verschachteln Sie die Definition, so dass es nicht von außen sichtbar ist.

3

Ich stimme auch mit ShreevatsaR, in diesem Beispiel würde ich den Helfer eine private Funktion machen.

Für andere Fälle, in denen Hilfsfunktionen im gesamten Modul sichtbar sein sollen, aber nicht exportiert werden, tendiere ich dazu, Funktionen mit '_' zu versehen. Sicher, es gibt die explizite Exportanweisung, aber während der Entwicklung tendiere ich dazu, alle Funktionen zu exportieren, um die interaktive Exploration zu erleichtern, z. in Ghci. Später füge ich die Liste der exportierten Funktionen hinzu, und die Unterleiste macht es leicht, sich daran zu erinnern, ob ich eine Funktion als lokal definieren wollte oder nicht.