Le Blog Invent with Python

Le Zen de Python de Tim Peters sont 20 lignes directrices pour la conception du langage Python. Votre code Python ne doit pas nécessairement suivre ces directives, mais il est bon de les garder à l’esprit. Le Zen de Python est un œuf de Pâques, ou une blague cachée, qui apparaît si vous courez import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Flat is better than nested.Sparse is better than dense.Readability counts.Special cases aren't special enough to break the rules.Although practicality beats purity.Errors should never pass silently.Unless explicitly silenced.In the face of ambiguity, refuse the temptation to guess.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!

REMARQUE: Mystérieusement, seulement 19 des directives sont écrites. Guido van Rosum aurait déclaré que le 20e aphorisme manquant est « une blague bizarre de Tim Peters. »

En fin de compte, ces lignes directrices sont des opinions qui peuvent être argumentées pour ou contre. Comme tous les bons ensembles de codes moraux, ils se contredisent parfois pour offrir le plus de flexibilité. Voici ma propre interprétation de ces aphorismes:

Le beau vaut mieux que le laid.

Les programmeurs écrivent souvent du code rapidement sans souci de lisibilité. Bien que le code n’ait pas besoin d’être lisible, le code du langage Python lui-même doit être pensé, cohérent et agréable à utiliser. Bien sûr, tous les scripts n’ont pas besoin d’être beaux, et la beauté est subjective, mais une grande partie de la popularité de Python est le résultat d’être si facile à travailler.

Explicite vaut mieux qu’implicite.

« Cet aphorisme est explicite », ce serait une explication terrible pour tout aphorisme. De même, il vaut mieux que le code soit verbeux et explicite. Vous devez éviter de cacher les fonctionnalités du code derrière des fonctionnalités de langage obscures qui nécessitent une familiarité pour bien comprendre.

Simple vaut mieux que complexe. Le complexe vaut mieux que le compliqué.

Ces deux aphorismes nous rappellent que construire n’importe quoi peut se faire à l’aide de techniques simples ou complexes. Avec un problème simple, comme la construction d’un nichoir, une solution simple est préférable. La construction d’un moteur de train diesel, en revanche, est un problème complexe qui nécessite des techniques complexes. Même si vous pouviez techniquement fabriquer un moteur de train diesel en utilisant des techniques de nichoirs, vous vous retrouveriez probablement avec un arrangement compliqué de pièces de nichoirs Rube Goldberg qui ne serait pas une solution idéale. Préférez la simplicité à la complexité, mais connaissez les limites de la simplicité.

Plat est meilleur que imbriqué.

Les programmeurs aiment organiser les choses en catégories, en particulier les catégories qui contiennent des sous-catégories qui contiennent d’autres sous-sous-catégories. Souvent, ces hiérarchies n’ajoutent pas autant d’organisation qu’elles ajoutent de la bureaucratie. Il est acceptable d’avoir du code dans un seul module ou classe de couche supérieure au lieu de le diviser en plusieurs sous-modules ou sous-classes. Si vous créez des packages et des modules qui nécessitent du code comme import spam.eggs.bacon.ham.foo.bar, vous compliquez votre code.

Clairsemé vaut mieux que dense.

Les programmeurs aiment souvent entasser autant de fonctionnalités dans le moins de code possible, comme des one-liners comme ce qui suit: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

La lisibilité compte.

Alors que strcmp() peut évidemment signifier la fonction « comparaison de chaînes » à quelqu’un qui programme en C depuis les années 1970, les ordinateurs modernes ont suffisamment de mémoire pour écrire le nom complet de la fonction. Ne supprimez pas les voyelles de vos noms ou n’écrivez pas de code trop laconique. Le code est lu plus souvent qu’il n’est écrit, donc le code explicite et lisible est plus important que le code laconique et non documenté.

Les cas spéciaux ne sont pas assez spéciaux pour enfreindre les règles. Bien que la praticité bat la pureté.

Ces deux aphorismes, qui se présentent comme un ensemble, se contredisent. La programmation regorge de « bonnes pratiques » que les programmeurs devraient rechercher dans leur code. Contourner ces pratiques pour un piratage rapide peut être tentant, mais peut conduire à un nid de rat de code incohérent et illisible. Cependant, se pencher vers l’arrière pour respecter les règles peut entraîner un code très abstrait et illisible. La tentative du langage de programmation Java d’adapter tout le code à son paradigme orienté objet se traduit souvent par beaucoup de code standard, même pour le plus petit programme. Marcher la ligne entre ces deux aphorismes devient plus facile avec l’expérience. Et avec le temps, vous apprendrez non seulement les règles, mais aussi quand les enfreindre.

Les erreurs ne doivent jamais passer silencieusement. Sauf si explicitement réduit au silence.

Ce n’est pas parce que les programmeurs ignorent souvent les messages d’erreur que le programme doit cesser de les émettre. Des erreurs silencieuses peuvent se produire lorsque les fonctions renvoient des codes d’erreur ou None au lieu de déclencher des exceptions. Ces deux aphorismes nous disent qu’il est préférable pour un programme de fail fast et de planter que de faire taire l’erreur et de continuer à exécuter le programme. Les bogues qui se produisent inévitablement plus tard seront plus difficiles à déboguer car ils sont loin de la cause d’origine. Bien que vous puissiez toujours choisir d’ignorer explicitement les erreurs causées par vos programmes, assurez-vous simplement de faire le choix conscient de le faire.

Face à l’ambiguïté, refusez la tentation de deviner.

Les ordinateurs ont rendu les humains superstitieux: Pour exorciser les démons dans nos ordinateurs, nous effectuons le rituel sacré de les éteindre puis de les allumer. Soi-disant, cela résoudra tout problème mystérieux. Cependant, les ordinateurs ne sont pas magiques. Si votre code ne fonctionne pas, il y a une raison et seule une pensée critique prudente le résoudra. Refusez la tentation d’essayer aveuglément des solutions jusqu’à ce que quelque chose semble fonctionner; souvent, vous avez simplement masqué le problème plutôt que de le résoudre.

Il devrait y avoir une — et de préférence une seule – façon évidente de le faire.

Ceci est un contre-pied à la devise du langage de programmation Perl, « Il y a plus d’une façon de le faire ! »Il s’avère qu’avoir trois ou quatre façons différentes d’écrire du code qui fait la même chose est une épée à double tranchant: vous avez de la flexibilité dans la façon d’écrire du code, mais maintenant vous devez apprendre toutes les manières possibles qu’il aurait pu être écrit pour le lire. Cette flexibilité ne vaut pas l’effort 3x ou 4x nécessaire pour apprendre un langage de programmation.

Bien que cela ne soit pas évident au début, sauf si vous êtes néerlandais.

Cette ligne est une blague. Guido van Rossum, le créateur et BDFL (Dictateur Bienveillant à Vie) de Python, est néerlandais. Cependant, même cet aphorisme n’empêchait pas Python d’incorporer trois façons différentes de formater des chaînes.

Maintenant, c’est mieux que jamais. Bien que jamais n’est souvent meilleur que * en ce moment *.

Ces deux aphorismes nous disent que le code qui se bloque ou se coince dans des boucles infinies est évidemment pire que le code qui ne le fait pas. Cependant, il vaut certainement mieux attendre la fin de votre programme que de le faire terminer trop tôt avec des résultats incorrects.

Si l’implémentation est difficile à expliquer, c’est une mauvaise idée. Si la mise en œuvre est facile à expliquer, cela peut être une bonne idée.

Python s’efforce de faciliter le travail du programmeur plutôt que de s’adapter à l’ordinateur pour qu’un programme s’exécute plus rapidement. Et les programmes doivent être compréhensibles non seulement par le programmeur qui l’a écrit, mais aussi par d’autres programmeurs qui gèrent le code. Ces deux aphorismes nous rappellent que si le code « haute performance » est si compliqué qu’il est impossible pour les programmeurs de le comprendre et de le déboguer, alors c’est du mauvais code. Mais hélas, ce n’est pas parce qu’il est facile d’expliquer le code d’un programme à quelqu’un d’autre que ce n’est pas un mauvais code. La programmation est difficile.

Les espaces de noms sont une excellente idée – faisons-en plus!Les espaces de noms

(ainsi que les étendues globales et locales) sont essentiels pour empêcher les noms d’un module ou d’une portée d’entrer en conflit avec les noms d’un autre. Mais rappelez-vous également que flat est meilleur que imbriqué: aussi grands soient-ils, les espaces de noms ne doivent être créés que pour éviter les conflits de noms et ne pas ajouter de catégorisation inutile.

Comme toutes les opinions sur la programmation, celles que j’ai écrites ici peuvent être contestées ou peuvent simplement être sans rapport avec votre situation. Se disputer sur la façon dont le code doit être écrit est rarement aussi productif que vous le pensez. (Sauf si vous écrivez un livre entier rempli d’opinions sur la programmation.)