Cas : je travaille dans une entreprise, écrivant une application en Python qui traite beaucoup de données dans des tableaux. Je suis le seul développeur de ce programme pour le moment, mais il sera probablement utilisé / modifié / étendu dans le futur (1-3 ans) par un autre programmeur, pour le moment inconnu de moi. Je ne serai probablement pas là directement pour aider alors, mais peut-être apporterais-je de l'aide par courrier électronique si j'en ai le temps.
Donc, en tant que développeur qui a appris la programmation fonctionnelle (Haskell), j’ai tendance à résoudre, par exemple, le filtrage de la manière suivante:
filtered = filter(lambda item: included(item.time, dur), measures)
Le reste du code est OO, ce ne sont que quelques cas où je veux le résoudre comme ceci, car il est beaucoup plus simple et plus beau selon moi.
Question : Est-ce que ça va aujourd'hui d'écrire du code comme ça?
- Comment un développeur qui n'a pas écrit / appris la PF réagit-il à un code comme celui-ci?
- Est-ce lisible?
- Modifiable?
Devrais-je écrire une documentation comme expliquer à un enfant ce que la ligne fait?
# Filter out the items from measures for which included(item.time, dur) != True
J'ai demandé à mon patron, et il a juste dit "La PF est une magie noire, mais si cela fonctionne et est la solution la plus efficace, alors c'est OK de l'utiliser."
Quelle est votre opinion à ce sujet? En tant que programmeur non-PF, comment réagissez-vous au code? Le code est-il "googable" afin que vous puissiez comprendre ce qu'il fait? J'aimerais des commentaires à ce sujet.
# Select the item's from measures for which included(item.time, dur) == True
:, éviter un double négatif améliore toujours la compréhension.Réponses:
Pour moi: Oui, mais j’en suis venu à comprendre que la communauté Python semble souvent considérer que la compréhension de liste est une solution plus propre que d’utiliser
map()
/filter()
.En fait, GvR a même envisagé de supprimer complètement ces fonctions.
Considère ceci:
De plus, ceci a l'avantage qu'une compréhension de liste retournera toujours une liste.
map()
etfilter()
d'autre part retournera un itérateur dans Python 3.Remarque: si vous souhaitez plutôt un itérateur, il vous suffit de le remplacer
[]
par()
:Pour être honnête, je ne vois pratiquement aucune raison d'utiliser
map()
oufilter()
en Python.Oui, certes, cependant, il y a une chose qui facilite cela: en faire une fonction, pas un lambda.
Si votre état devient plus complexe, l’échelle sera beaucoup plus simple et vous permettra également de réutiliser votre chèque. (Notez que vous pouvez créer des fonctions dans d'autres fonctions, cela peut le garder plus près de l'endroit où il est utilisé.)
Il recherche la documentation Python dans Google et sait comment cela fonctionne cinq minutes plus tard. Sinon, il ne devrait pas programmer en Python.
map()
etfilter()
sont extrêmement simples. Ce n'est pas comme si vous leur demandiez de comprendre les monades. C'est pourquoi je ne pense pas que vous ayez besoin d'écrire de tels commentaires. Utilisez de bons noms de variables et de fonctions, le code est alors presque explicite. Vous ne pouvez pas anticiper sur les fonctionnalités qu'un développeur ne connaît pas. Pour autant que vous sachiez, le prochain développeur pourrait ne pas savoir ce qu'est un dictionnaire.Ce que nous ne comprenons pas est généralement illisible pour nous. Ainsi, vous pourriez affirmer que ce n'est pas moins lisible qu'une compréhension de liste si vous ne les avez jamais vues auparavant. Mais comme Joshua l'a mentionné dans son commentaire, je pense moi aussi qu'il est important d'être cohérent avec ce que les autres développeurs utilisent - du moins si cette alternative ne fournit aucun avantage substantiel.
la source
map
etfilter
faire en python 3.reduce
comme contre-exemple que vous pouvez toujours utiliser un argument de compréhension de liste , car il est relativement difficile de le remplacerreduce
par un générateur en ligne ou une compréhension de liste.Étant donné que la communauté des développeurs regagne de l’intérêt pour la programmation fonctionnelle, il n’est pas rare de voir une programmation fonctionnelle dans des langages qui étaient à l’origine entièrement orientés objet. Un bon exemple est le C #, où les types anonymes et les expressions lambda permettent d’être beaucoup plus courts et expressifs grâce à la programmation fonctionnelle.
Cela étant dit, la programmation fonctionnelle est étrange pour les débutants. Par exemple, lors d’une formation, j’ai expliqué aux débutants comment améliorer leur code grâce à la programmation fonctionnelle en C #, certains d’entre eux n’étaient pas convaincus et d’autres ont dit que le code original leur était plus facile à comprendre. L'exemple que je leur ai donné était le suivant:
Code avant refactoring:
Même code après refactoring en utilisant FP:
Cela me fait penser que:
ne vous inquiétez pas si vous savez que le prochain développeur qui gérera votre code aura une expérience globale suffisante et une certaine connaissance de la programmation fonctionnelle, mais:
sinon, évitez la programmation fonctionnelle ou mettez un commentaire explicite expliquant en même temps la syntaxe, les avantages et les inconvénients de votre approche par rapport à une programmation non fonctionnelle.
la source
Je suis un programmeur non-PF et récemment, je devais modifier le code de mon collègue en JavaScript. Il y avait une demande Http avec un rappel qui ressemblait beaucoup à la déclaration que vous avez incluse. Je dois dire que cela m'a pris un certain temps (environ une demi-heure) pour tout comprendre (le code dans l'ensemble n'était pas très volumineux).
Il n'y avait pas de commentaires, et je pense qu'il n'y en avait aucune nécessité. Je n'ai même pas demandé à mon collègue de m'aider à comprendre son code.
Étant donné que je travaille depuis environ un an et demi, je pense que la plupart des programmeurs seront en mesure de comprendre et de modifier ce code, comme je l’ai fait.
En outre, comme Joachim Sauer l'a dit dans son commentaire, il existe souvent des morceaux de PF dans de nombreuses langues, comme C # (indexOf, par exemple). Tant de programmeurs non-PF traitent cela assez souvent, et l'extrait de code que vous avez inclus n'est pas quelque chose de terrible ou d'incompréhensible.
la source
Je dirais certainement oui!
Il existe de nombreux aspects de la programmation fonctionnelle et l'utilisation de fonctions d'ordre supérieur, comme dans votre exemple, n'en est qu'un.
Par exemple, j’estime que l’écriture de fonctions pures est extrêmement importante pour tout logiciel écrit dans n’importe quelle langue (par «pur», j’entends pas d'effets secondaires), car:
J'évite aussi souvent de muter les valeurs et les variables - un autre concept emprunté à la PF.
Ces deux techniques fonctionnent bien en Python et dans d'autres langages qui ne sont généralement pas classés comme fonctionnels. Ils sont souvent même pris en charge par le langage lui-même (c'est-
final
à- dire les variables en Java). Ainsi, les futurs programmeurs de maintenance ne seront pas confrontés à une énorme barrière pour comprendre le code.la source
Nous avons eu la même discussion sur une entreprise pour laquelle j'ai travaillé l'année dernière.
La discussion a porté sur le "code magique" et si cela devait être encouragé ou non. En y regardant un peu plus, il semblait que les gens avaient des points de vue très différents sur ce qui était en réalité un "code magique". Ceux qui ont abordé la discussion ont semblé vouloir dire principalement que les expressions (en PHP) qui utilisaient le style fonctionnel étaient du "code magique", tandis que les développeurs originaires d'autres langues utilisant davantage le style de la PF dans leur code semblent penser que le code magique est plutôt lorsque vous faites l'inclusion dynamique de fichiers à travers les noms de fichiers et ainsi de suite.
Nous ne sommes jamais parvenus à une bonne conclusion à ce sujet. Mieux encore, les gens pensent que le code qui semble inconnu est "magique" ou difficile à lire. Alors, est-ce une bonne idée d'éviter un code qui semble inconnu des autres utilisateurs? Je pense que cela dépend de l'endroit où il est utilisé. Je m'abstiendrais d'utiliser des expressions de style fp (inclusion de fichier dynamique, etc.) dans une méthode principale (ou dans des parties centrales importantes d'applications) dans laquelle les données devraient être tunnelisées de manière claire, intuitive et facile à lire. D'autre part, je ne pense pas que l'on devrait avoir peur de repousser les limites, les autres développeurs apprendront probablement la PF rapidement s'ils sont confrontés au code de la PF et auront peut-être une bonne ressource interne à consulter sur ces questions.
TL; DR: évitez en haut la partie centrale des applications (qui doivent être lues pour avoir une vue d'ensemble des fonctionnalités de l'application). Sinon utilisez-le.
la source
La communauté C ++ a récemment eu le lambda aussi, et je crois qu’elle a à peu près la même question. La réponse peut ne pas être la même, cependant. L'équivalent C ++ serait:
Ce
std::copy
n’est pas nouveau, et les_if
variantes ne le sont pas non plus, mais le lambda l’est. Pourtant, il est défini assez clairement dans son contexte: ildur
est capturé et donc constant,Item i
varie dans la boucle et lareturn
déclaration unique effectue tout le travail.Cela semble acceptable pour de nombreux développeurs C ++. Je n'ai cependant pas échantillonné d'opinions sur les lambda d'ordre supérieur et je m'attendrais à beaucoup moins d'acceptation.
la source
Envoyez un extrait de code à un autre développeur qui ne parle pas aussi bien le python, et demandez-lui s’il peut passer 5 minutes à vérifier le code pour voir s’il le comprend.
Si oui, vous êtes probablement prêt à partir. Sinon, vous devriez essayer de le clarifier.
Votre collègue pourrait-il être stupide et ne pas comprendre quelque chose qui devrait être évident? Oui, mais vous devriez toujours programmer conformément à KISS.
Peut-être que votre code est plus efficace / beau / élégant qu'une approche plus simple et plus sûre des imbéciles? Ensuite, vous devez vous demander: dois-je faire cela? Encore une fois, si la réponse est non, alors ne le faites pas!
Si, après tout cela, vous pensez toujours que vous avez besoin et que vous voulez le faire de la manière de la PF, alors, certainement, faites-le. Faites confiance à votre instinct, ils sont mieux adaptés à vos besoins que la plupart des gens sur n'importe quel forum :)
la source