Zen of Python

Origem: Wikipédia, a enciclopédia livre.

O Zen do Python é uma coleção de 19 princípios orientadores, na forma de poema, com uma série de aforismos, para escrever programas de computador que influenciam o design da linguagem de programação Python[1]. O engenheiro de software Tim Peters escreveu esse conjunto de princípios e o publicou na lista de discussão do Python em 1999[2]. A lista de Peters deixou em aberto o vigésimo princípio "para Guido preencher", referindo-se a Guido van Rossum, o autor original da linguagem Python. A vaga para o vigésimo princípio não foi preenchida.[3]

O Zen of Python de Peters foi incluído como entrada número 20 nas propostas oficiais de aprimoramento do Python (PEP), lançadas em domínio público.[4] Ele também está incluído como um easter egg no interpretador Python[4], que pode ser exibido digitando:

>>> import this

Princípios[editar | editar código-fonte]

Os princípios que constam no Zen of Python são (originalmente em Inglês):

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!

A versão em Português seria a seguinte:

Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Linear é melhor do que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para quebrar as regras.
Ainda que praticidade vença a pureza.
Erros nunca devem passar silenciosamente. 
A menos que sejam explicitamente silenciados.
Diante da ambiguidade, recuse a tentação de adivinhar.
Dever haver um — e preferencialmente apenas um — modo óbvio para fazer algo.
Embora esse modo possa não ser óbvio a princípio a menos que você seja holandês.
Agora é melhor que nunca.
Apesar de que nunca normalmente é melhor do que *exatamente* agora
Se a implementação é difícil de explicar, é uma má ideia
Se a implementação é fácil de explicar, pode ser uma boa ideia
Namespaces são uma grande ideia — vamos ter mais dessas!

Ver também[editar | editar código-fonte]

Referências[editar | editar código-fonte]

  1. «Code Style — The Hitchhiker's Guide to Python». docs.python-guide.org. Consultado em 8 de junho de 2020 
  2. Peters, Tim. «"The Python Way"». Fri Jun 4 01:15:13 EDT 1999. Consultado em 8 de junho de 2020 
  3. Cory Althoff (2017). The Self-Taught Programmer: The Definitive Guide to Programming Professionally. [S.l.]: ‎ Self-Taught Media. ISBN 0999685902 
  4. a b «PEP 20 -- The Zen of Python». Python.org (em inglês). Consultado em 8 de junho de 2020