Que signifie Zen de Python ?

Tous ceux qui ont utilisé Python savent en gros que taper import this dans l'interpréteur interactif affichera The Zen of Python de Tim Peters, mais son gargouillis La déclaration est un peu déroutante, alors je voulais pour partager mon expérience avec celui-ci, ainsi que ma traduction.

The Zen of Python, by Tim Peters
 
Beautiful 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!

Traduit et expliqué

Zen de Python par Tim Peters

Mieux vaut beau que laid (Python vise à écrire du beau code)

La clarté vaut mieux que l'obscurité (un beau code doit être clair, avec des conventions de dénomination et des styles similaires)

La simplicité vaut mieux que la complexité (un beau code doit être simple et ne doit pas avoir d'implémentations internes complexes)

La complexité vaut mieux que l'encombrement (si la complexité est inévitable, il ne devrait y avoir aucune relation difficile à comprendre entre les codes et l'interface doit rester simple)

La planéité vaut mieux que l'imbrication (un beau code devrait être plat, il ne peut pas y avoir trop d'imbrication)

L'espacement est meilleur que la compacité (un beau code a un espacement approprié, ne vous attendez pas à ce qu'une seule ligne de code résolve le problème)

Lisibilité est important (les beaux codes sont lisibles)

Ne violez pas ces règles (ces règles sont primordiales) même au nom de l'aspect pratique des exceptions

Ne tolérez pas toutes les erreurs sauf si vous êtes absolument besoin (justement Attraper les exceptions, n'écrivez pas sauf :pass style code)

Quand il y a plusieurs possibilités, n'essayez pas de deviner

mais essayez d'en trouver une, de préférence la seule évidente une solution (en cas de doute, utilisez une méthode exhaustive)

Bien que ce ne soit pas facile, car vous n'êtes pas le père de Python (le néerlandais fait ici référence à Guido)

Il serait peut-être préférable de le faire mieux que de ne pas le faire, mais le faire sans réfléchir est pire que ne pas le faire (réfléchissez bien avant de le faire)

Si vous ne pouvez pas décrire votre plan aux autres, ce n'est certainement pas un bon plan ; vice versa (critères d'évaluation du plan)

L'espace de noms est une merveilleuse idée et nous devrions en faire davantage usage (plaidoyer et appel)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!