Je suis jolie nouvelle à Python et je me demandais si ceci: est une bonne pratique. P> Puis-je retourner d'une boucle comme ci-dessus ou devrais-je utiliser une boucle de temps, comme si? P> def func(self, foo):
found = false
while(not found & i < len(self.list)):
found = foo.boolfunc()
++i
return found
6 Réponses :
C'est une bonne pratique.
Mon professeur Java nous avertit de ne jamais utiliser des pauses dans nos boucles
Pourquoi est-ce? "Jamais" est un mot fort en informatique et ne devrait jamais (...) être utilisé. 1)
1) à l'exception de "goto" ... nous avons tous nos pépins d'animaux. ; -)
Merci! Eh bien, il dit que c'est une mauvaise habitude qui peut (presque?) toujours être remplacée par quelque chose de mieux.
il est presque toujours possible de remplacer une pause, qu'il s'agisse d'une question d'opinion
@JK: C'est toujours possible de remplacer break avec une condition de sortie. Il y a en fait une preuve de cela, c'est le "flux de contrôle dans la théorie des preuves de la programmation structurée".
@Konrad Rudolph: Pour les étudiants apprenant à programmer, "Jamais" n'est jamais assez fort. Pour les étudiants, vous devez toujours utiliser des absolus, sinon ils ne comprennent jamais que les conditions de bord sont vraiment des conditions de pointe.
@ S.Lott: True, je l'utilise aussi bien, même sur des sujets quelque peu controversés que je dois admettre. Mais ici, le professeur est faux (c'est-à-dire ne pas partager mon avis). ;-)
Toujours est un mot difficile, la mise en garde était au cas où quelqu'un définit une langue qui utilise seulement une pause, pas très utile mais contredire ce genre d'affirmation
@JK: une langue qui utilise seulement une pause? Vous voulez dire assembleur? Si vous n'avez aucune alternative à la pause, le «toujours» est toujours vrai; S'il n'y a pas d'alternative, il est exclu de l'ensemble a priori .
Il n'y a rien de mal avec votre exemple, mais il est préférable d'écrire
Merci, je ne suis pas encore familier avec les outs de Python, mais des choses comme ça me donne envie d'apprendre plus
Docs pour tout (): docs.python.org/library/functions.html#any < / a>. Docs pour les expressions génératrices: docs.python.org/tatudial/classes.html#generator -Expressions
Votre professeur préconise une pratique appelée "point de retour unique", qui indique essentiellement que tout bloc de code ne devrait avoir qu'un seul point de sortie. Les pauses dans des boucles sont un peu distinctes de cela, mais généralement regroupées.
C'est une opinion controversée, de dire le moins, et certainement pas aussi difficile et rapide une règle que "ne jamais utiliser goto". Cela vaut probablement la peine de le faire son chemin - vous pouvez l'apaiser et voir également l'avantage des deux approches, mais la plupart des gens ne sont probablement pas trop stricts sur un seul point de retour si la violation de son code est plus lisible.
"Sortir d'une boucle" peut facilement se transformer à une mauvaise pratique car elle dissimule l'état de terminaison de la boucle.
Si votre Si votre condition de sortie est Si votre condition de sortie est En effet, Cette question à ce sujet montre que la présence d'un SIMPLE En règle générale, toutes les choses "précoce" "(la déclaration Si vous développez votre programme en raisonnant les déclarations nécessaires pour créer la condition post-condition nécessaire, vous n'aurez jamais besoin de Aussi, notez que tous les conseils pour éviter "sinon" considéré comme nocif dans Python?
Si la condition de sortie d'une boucle avec une pause (ou précoce Dans cet exemple, ils sont si est de complexité modérée, il peut devenir peu claire quelle condition postérieure à la boucle établie.
si vous fait plus de mal que de bien.
ESSAYEZ Le bloc peut conduire à des conditions afin de déranger un morceau de code clairement incorrect et ne pouvait pas être facilement débogué.
, en particulier) entraînent des problèmes de création d'une preuve formelle. (La déclaration ele a des problèmes similaires.)
break ou un début retour car vous pouvez " t créer facilement ces déclarations en utilisant des méthodes formelles.
Break ou ele mèneront à la haine mail et à la baisse. Pour des raisons inexplicables, la recherche de près dans certaines constructions de programmation est une mauvaise chose.
retour ) n'est pas évident , vous devez retravailler les choses à retravailler il
@ S.Lott: Dans quelle mesure pensez-vous des preuves formelles? Dans mon expérience, pas du tout, car même des algorithmes simples sont beaucoup trop complexes et cette complexité n'est pas modifiée si vous utilisez une sortie précoce ou non. En fait, la boucle invariante ne change pas de la manière. (Pas mon bowvote, BTW. Votre point est toujours bien fait.)
@Konrad Rudolph: Ils sont essentiels. Dans une langue raisonnablement utilisable, les "primitives" - déclarations, types de données intégrés, etc. - aura des preuves que ces choses fonctionnent réellement comme annoncé. Certaines preuves sont très formelles, d'autres sont modérément formelles. Mais sans un certain niveau de confiance, les gens perdent lentement la confiance dans la langue.
Ces approches formelles sont directement des chances avec les aspects pratiques de la rédaction de Code, ce qui est probablement pourquoi de tels conseils sont révélés. Toute personne qui a déjà essayé de tracer une routine complexe qui utilise 10 drapeaux au lieu de 10 déclarations de 10 reviennent -1 de ces conseils immédiatement.
Pour être honnête, je n'ai jamais entendu cela, et je doute plutôt. Bien sûr, les bibliothèques de mathématiques utiliseront des preuves formelles et quelques autres choses. Mais à part ça ... pas de grande présence. En fait, peu de bons programmeurs utilisent des preuves formelles du tout, si des «codeurs au travail» constituent une indication.
@ROMKYNS: "praticité" n'est pas le problème. Le problème est évidemment correct . Si votre code est bon, vous n'avez pas besoin d'une preuve formelle de chaque ligne. Si votre code est mauvais, la discipline mentale de la preuve formelle peut aider à réduire le méchant.
@Konrad rudolph. La plupart (98%) des programmeurs n'utilisent pas de méthodes formelles. Toutefois, lorsque vous lisez le code des bibliothèques OS, des structures de données, des interprètes, etc., vous verrez des traces de méthodes formelles dans les commentaires. Beaucoup, de nombreux éléments de code ont été examinés par des méthodes formelles pour s'assurer qu'ils travaillent comme annoncé. Il ne faut pas faire des efforts supplémentaires pour prouver qu'une boucle se termine ou que l'algorithme de coloration rouge-noir dans un Treeemap répond en réalité à toutes les exigences. Il est plus facile que d'écrire des tests d'unité sans fin.
Il convient de mentionner que dans Python, Vous pourriez donc écrire:
"EXITE EXITE" est un style parfaitement pythonique (lors de la garantie: la réponse du gnibbler souligne correctement que pour votre cas d'utilisation spécifique, il est préférable d'intégrer [en python 2.5 et mieux]], qui est préférable) et contribue souvent à réaliser le pythonique L'objectif de "plat est meilleur que jeté". Et Avantages parfois revendiqués pour l'alternative "point de sortie unique" incluent l'existence d'un seul «goulot d'étranglement de sortie» à laquelle le nettoyage peut être effectué. Mais puisque les exceptions sont toujours possibles, vous n'avez pas savoir que votre seul Article de Knuth "Programmation structurée avec des instructions GoTo" (PDF ) - Un incroyable article visionnaire de 1974 par l'homme que beaucoup considèrent comme une légende vivante d'informatique, théorique et pratique - vaut bien la peine de lire. Toute personne qui doute de l'applicabilité de l'article à Python devrait prendre en compte la citation courte suivante:
périphériques comme l'indentation, plutôt que
Les délimiteurs, pourraient devenir réalisables pour
exprimer la structure locale dans le
langue source.
vingt ans avant Python 1.0 a été publié, Knuth déjà prévoyait l'aspect clé de la syntaxe qui devientirait une telle marque de python (et, indépendamment, Haskell , libéré un peu plus tôt que Python - de la discussion personnelle avec Knuth, Peyton Jones et Van Rossum Je peux attester qu'ils prétendent tous que ces trois inventions de "indentation pour le groupement" étaient totalement indépendantes les unes des autres, mais un cas de "grands esprits se ressemblent" - ou, dans les mots de Charles Fort ", il n'était que du temps à la vapeur "; -).
Les preuves formelles du code, y compris la sortie tôt, ne sont bien sûr pas une noille plus difficile que pour un code équivalent avec un point de sortie unique, si rien d'autre parce que la célèbre preuve de Corrado Böhm et Giuseppe Jacopini montre comment effectuer une transformation mécanique de tout organigramme à un ne contenant que la séquence, la sélection et la répétition (mais bien sûr, le programme transformé - tout comme tout autre programme tente d'éviter le style de sortie précoce - est susceptible d'avoir plus de nidification que nécessaire et une variable «statut» supplémentaire «Status», qui interfèrent avec la lisibilité, la démolition et l'efficacité - faisant une sortie précoce beaucoup supérieure dans les langues qui le soutiennent bien). pour est généralement la bonne façon de faire une boucle en python, au niveau de l'application: s'il y a une logique de boucle compliquée (comme cela pourrait justifier un pendant ), il est souvent préférable de Poussez-le quand même un générateur auxiliaire.
retour est un goulot d'étranglement unique, même si vous l'avez: la bonne façon d'assurer un bon nettoyage est , à la place, le avec instruction (en 2.6 ou 2.5 avec une "importation du futur"; pour les versions plus anciennes de Python, le clunkier mais toujours utile essayer / / enfin à la place).
@Konrad, content que tu aies aimé ça! -)
Votre version alternative n'est pas très bonne python. Utilisez
et pour logique et. Évitez& sauf si vous faites des opérations bit-sage.Votre professeur Java a tort.
Votre professeur Java vous faisait une grande faveur en vous faisant penser à cela.
FOO est la variable de boucle, pourquoi FOO est-elle transmise à la fonction?
@codeape, je pense que les foo sont des espaces réservés pour cet exemple