Question

En programmation fonctionnelle, il est souvent important d’optimiser les "boucles". le code doit être récursif. Les algorithmes récursifs de queue sont généralement divisés entre deux fonctions, une qui configure le cas de base et une autre qui implémente la boucle réelle. Un bon exemple (académique) serait la fonction inverse.

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; reverse_helper " n'est pas vraiment un bon nom descriptif. Cependant, " reverse_recursive_part " est juste maladroit.

Quelle convention de dénomination utiliseriez-vous pour les fonctions d’aide de ce type?

Était-ce utile?

La solution

J'ai tendance à ajouter " _recurse " jusqu'à la fin. Donc, "reverse_recurse". Je ne sais pas d'où je viens. J'aime laisser la fonction de base simple comme dans votre exemple. Il a tendance à être le "public" fonction et le fait qu’elle utilise une fonction d’aide pour effectuer l’itération n’a aucune importance pour l’appelant. En javascript, je vais parfois jusqu'à cacher la fonction itérative via une fermeture, pour que ce soit vraiment clair, il ne faut pas l'appeler directement.

Autres conseils

Vous pouvez appeler la fonction d'assistance comme bon vous semble, et cela n'aura aucune importance tant que vous ne placez pas la fonction d'assistance dans le champ "global". espace de noms. Ajoutant simplement un " prime " semble une pratique courante. :) Par exemple, à Haskell,

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

J'utilise toujours do_, comme " do_compute " avec "calcul". Je le trouve assez descriptif, car c’est effectivement la partie de la fonction qui exécute l’action, alors que le "calcul" qui s’appelle a besoin d’avoir un nom descriptif simple pour le monde extérieur.

Je suis d’accord avec ShreevatsaR, si vous ne rendez pas la fonction d’aide de premier niveau (ou pire, placez-la dans la liste des exportations), le nom n’importe pas. J'ai tendance à appeler les fonctions auxiliaires f et g .

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

Je viens d'utiliser ce schéma de nommage pour de petites fonctions (sinon, je ne sais pas à quoi le f fait référence). Encore une fois, pourquoi voudriez-vous jamais écrire de grandes fonctions?

Toutefois, si vous souhaitez exporter votre fonction 'helper' car elle pourrait être utile à d'autres, je l'appellerais:

reverseAccumulator

Comme zip et zipWith de Haskell. Mais je n’appellerais pas ces fonctions "auxiliaires", zipWith n’est qu’une fonction générique et zip est l’implémentation par défaut (probablement celle qui est la plus utilisée).

Je suis également d'accord avec ShreevatsaR, dans cet exemple, je ferais de l'aide une fonction privée.

Pour les autres cas où j'ai besoin que les fonctions d'assistance soient visibles dans tout le module, mais pas exportées, j'ai tendance à préfixer les fonctions avec '_'. Bien sûr, il existe une déclaration explicite sur les exportations, mais au cours du développement, j’ai tendance à exporter toutes les fonctions pour faciliter l’exploration interactive, par exemple. en ghci. Plus tard, j’ajoute la liste des fonctions exportées et la barre de soulignement facilite la mémorisation du choix d’une fonction locale ou non.

J'utilise aux ou foo_aux (pour la fonction principale foo ) et imbrique la définition pour qu'elle ne soit pas visible de l'extérieur.

configurer et exécuter

exemple:

function whateverSetup() { ... }
function whateverExecute() { ... }
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top