Cada linguagem de programação pode ter suas próprias regras e até mesmo uma filosofia para manter as boas práticas e a sua identidade. E a linguagem Python também tem a sua. Em inglês é chamada de "The Zen of Python" e você pode conhecê-la pesquisando por aí na internet ou ainda executando um comando diretamente no seu código.
Executando o comando para ver os princípios
Para poder descobrir quais são os princípios da filosofia do Python, você pode executar eu seu código o seguinte comando:
import this
Ao executar este comando, em seu terminal vai aparecer o seguinte texto:
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!
Entendendo a tradução de "The Zen of Python"
Em português, os tópicos da filosofia da linguagem de programação Python seria:
Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Plano é melhor que aglomerado.
Esparso é melhor que denso.
Legibilidade faz diferença.
Casos especiais não são especiais o bastante para quebrar as regras.
Embora a 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.
Deve haver um -- e preferencialmente só um -- modo óbvio para fazer algo.
Embora esse modo possa não ser óbvio à primeira vista a menos que você seja holandês.
Agora é melhor que nunca.
Embora nunca frequentemente seja melhor 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 fazer mais dessas!
Quem é Tim Peters
Quem criou a linguagem de programação Python foi Guido van Rossum, então talvez pareça estranho ter um outro nome ali na apresentação desse easter egg que é The Zen of Python.
Tim Peters é um desenvolvedor de software conhecido por suas contribuições à linguagem Python - já recebeu o prêmio PSF Distinguished Service Award pela Python Software Foundation - e por ter criado um algoritmo chamado Timsort.
Quando Tim disponibilizou esses 19 princípios, ele tinha a ideia de que o próprio Guido criaria o 20º item da filosofia, que na verdade nunca foi feita.
O que significam os 19 itens em "The Zen of Python"
Conforme a gente lê esses princípios, pode parecer um pouco confuso ou até contraditório, mas conforme vamos evoluindo em nossos aprendizados de Python, talvez alguns itens fiquem mais claros.
No site da wiki da comunidade Python Brasil tem um link para uma tentativa de explicação de The Zen of Python, resultado de um e-mail, porque conforme a própria comunidade afirma, talvez qualquer explicação seja um pouco incompleta sobre todos os 19 itens.
Quero compartilhar aqui um pouco do que penso sobre esses itens - e na minha visão, parece que tudo está relacionado a legibilidade - e gostaria de saber a sua opinião nos comentários!
Reforço que trarei uma interpretação minha. Não estou dizendo que é o certo ou errado. A ideia é termos a discussão sobre a filosofia de maneira saudável.
1. Bonito é melhor que feio.
Acredito que este item esteja muito relacionado a legibilidade e facilidade de se entender a linguagem Python, ainda que um código bonito possa ser algo relativo.
2. Explícito é melhor que implícito.
Entendo que esse item poderia ser parte de todas as linguagens. E, novamente, interpreto que esteja muito relacionado a legibilidade do Python. Por exemplo, ao invés de misturar diversos itens de cálculo ou outras operações, por que não separar em funções com nomes explícitos e fazer o código ser mais fácil de ser lido?
3. Simples é melhor que complexo.
Sempre tem formas complexas de se escrever um código. E conforme a gente evolui na linguagem, a gente vai aprendendo essas formas. Mas nem sempre elas serão legíveis para quem vai ler o código pela primeira vez. Ou ainda reler o código depois de um tempo sem mexer nele.
4. Complexo é melhor que complicado.
Mesmo ponto que eu trouxe no item 3. Pode ser legal aprender formas complexas de se escrever um código e resolver 5 linhas em apenas 1. Mas e como vai ser possível entender aquele código depois?
5. Plano é melhor que aglomerado.
Esse aqui eu não tinha entendido muito bem, mas ao pesquisar sobre ele, vi que a maioria das pessoas relacionou este item a organização do código. O que faz bastante sentido. Ao invés de colocar tudo de uma vez dentro de uma única função ou dentro de um único arquivo, talvez seja mais interessante organizar melhor as estruturas (quem sabe até mesmo semanticamente).
6. Esparso é melhor que denso.
Confesso que também não tinha entendido muito este aqui. Mas ao pesquisar, entendi que tem relação à densidade e quantidade de código que pode ser colocado em uma determinada função, por exemplo. Talvez seja melhor quebrar em mais linhas para deixar mais legível. (Legibilidade de novo, tá vendo?).
7. Legibilidade faz diferença.
E falando em legibilidade, no meu ponto de vista esse é o centro de todos os itens levantados nessa filosofia. Até mesmo porque, o Python também é bastante conhecido pela facilidade de leitura de código, justamente pela forma como é escrito. E isso faz diferença para todes, não só para quem está começando, mas mesmo para você que talvez já tenha bastante experiência e precisará revisitar códigos legados para manutenção. Nada pior do que olhar para um código e não entender bulhufas do que ele quer dizer, né?
8. Casos especiais não são especiais o bastante para quebrar as regras.
Às vezes dá uma certa vontade de fazer de qualquer jeito um determinado caso em nosso código só para evitar trabalho de ter que seguir boas práticas ou regras de um determinado projeto em que estamos envolvides. Isso pode ser uma grande armadilha, talvez em algumas situações, valha mais a pena seguir as regras.
9. Embora a praticidade vença a pureza.
Continuidade do item 8, né? E é engraçado que tenha a palavra "pureza" nele.
10. Erros nunca devem passar silenciosamente.
Olha, uma excelente boa prática é termos as exceções mapeadas em nossos códigos e com mensagens apropriadas para elas. Erros vão acontecer e é importante nesses momentos entender o que, de fato, está acontecendo. Isso ajuda a gente que está desenvolvendo e também quem vai usar o sistema no final.
11. A menos que sejam explicitamente silenciados.
Mas aí a gente tem que saber que está assumindo um risco. Tudo bem que alguns riscos são aceitáveis. Então acho que é mais entender como gerenciar isso da melhor forma, de acordo com a criticidade do sistema.
12. Diante da ambiguidade, recuse a tentação de adivinhar.
A gente tem uma mania muito louca de querer adivinhar as coisas ao invés de olhar diretamente o que está acontecendo, às vezes. Então pare, olhe os erros com calma. Pratique a arte de debugar seu código quando necessário. Melhor ir direto na fonte.
13. Deve haver um -- e preferencialmente só um -- modo óbvio para fazer algo.
Complicada essa parte aqui da filosofia. Acho que ele quis dizer que deveria ter uma forma de fazer isso e, parece que também foi uma provocação as outras linguagens de programação pelo que vi em outras pesquisas. Mas existem mesmo tantas formas de resolver um mesmo problema que não sei se esse item deveria mesmo fazer parte de The Zen of Python. De qualquer forma, acho que entendo. Querem tanto que a legibilidade e a simplicidade do Python seja óbvia, que na visão de quem criou essa filosofia o mais simples é sempre o melhor.
14. Embora esse modo possa não ser óbvio à primeira vista a menos que você seja holandês.
Aqui eu não sei se era também pra ser algum tipo de provocação, mas confesso que prefiro deixar este item de lado.
15. Agora é melhor que nunca.
Talvez pareça um tanto quanto contraditório, mas eu interpreto que este item queira mostrar pra gente que devemos resolver um código logo e na hora ao invés de ficar complicando. Fazer algo mais prático para resolver o problema. A parte do contraditório talvez seja porque pareça que estamos falando "faz de qualquer jeito e depois marca lá a melhoria como débito técnico". Mas, de novo, a galera defende tanto a simplicidade e legibilidade do Python que talvez tenha sido mais nesse ponto que estavam tocando e não na "entrega de qualquer jeito".
16. Embora nunca frequentemente seja melhor que exatamente agora.
Entendo mais como um complemento do item 15. Porque aí sim reforça toda a ideia de fazer o código da melhor forma possível: simples, legível, funções claras e objetivas etc.
17. Se a implementação é difícil de explicar, é uma má ideia.
Acho que este item é bem claro. E continua dando mais força a ideia de que é melhor pensar com calma e talvez escrever o código de outras formas ao invés de resolver tudo numa linha única e que ninguém vai entender depois. É só um exemplo, mas acho que você entendeu.
18. Se a implementação é fácil de explicar, pode ser uma boa ideia.
E é legal como este ponto foi colocado como "pode ser uma boa ideia" e não uma afirmação concreta e sem dúvidas como "é uma boa ideia". Até porque simplicidade também pode ser algo relativo, certo? Nem sempre o simples é igual para todes. E se for um trabalho em time talvez seja interessante ter essa discussão para definir a melhor forma de desenvolver uma solução.
19. Namespaces são uma grande ideia -- vamos fazer mais dessas!
Organização e semântica pode fazer toda a diferença, principalmente para separar contextos em seu projeto. Então acredito que seja isso que esteja sendo enfatizado aqui.
Devo seguir todos os 19 itens de The Zen of Code?
Depende. (Sênior o suficiente essa resposta?). A gente vive estudando boas práticas em diversos aspectos de projetos de software, mas muitas vezes ao chegar no mercado de trabalho, tudo isso é ignorado.
Isso significa que devo ignorar as boas práticas? Não. Mas é só uma reflexão de que, às vezes, a entrega precisa ser feita para ontem. E a realidade do dia-a-dia de uma pessoa desenvolvedora pode ser bastante relativa.
Existem projetos que você, talvez, terá a oportunidade de proporcionar legibilidade e qualidade ao seu código. E isso poderá fazer toda a diferença na sua vida profissional. Mas é importante alinharmos aqui as expectativas de que nem sempre será assim. Infelizmente. Mas isso é discussão para um outro artigo ou um papo no bar com a comunidade.
O que achou? Curtiu? Deixe suas impressões também nos comentários e bora discutir mais sobre esse assunto!
Nos encontramos nos comentários e, quem sabe, nos próximos artigos. Até lá!
Top comments (4)
Sobre o item 1, eu lembro da elegância matemática, onde uma expressão simplificada consegue descrever a relação entre diversas variáveis, e isso é considerado bonito ou elegante.
Sobre o item 2, existem linguagens que vão na contramão, como Ruby ou PHP antigamente, por exemplo, que um módulo ou arquivo é importado com tudo que vem dentro, e quando se importa diversos, não se sabe depois de onde tal função veio. O mesmo ocorre ao usar o
*noimportdo Java. Esse eu acho que é o exemplo mais simples, mas isso pode ocorrer no código também, onde um certo comportamento ou tratativa pode não estar explícito no código, dificultando o seu entendimento.Eu também gosto da versão em quadrinhos:
Nossa, bem lembrado sobre o ponto 1, faz todo sentido. E concordo sobre o que trouxe do item 2.
Valeu demais por contribuir. E valeu também por compartilhar os quadrinhos, eu ainda não conhecia!
Penso mais na 13 e 14 como aquela frase:
É isso, adorei!