Fique Zen com Python
📍Introdução
Com certeza, se você conhece o Python hoje foi por que algo te chamou a atenção. Deixa eu adivinhar… A runtime dele! Acertei? Claro que não, foi a escrita de código. A forma simples e objetiva dessa linguagem é um dos fatores que sem dúvida leva ela ser uma das mais queridas e em ascensão no mundo de programação, como mostram algumas pesquisas.
Mas uma das melhores coisas dentro dessa língua das serpentes é um easteregg conhecido com Zen of Python, onde temos um conjunto de princípios (ou filosofia) para escrever código a la Python. Mas estas práticas propostas por Tim Peters (conhecida também por PEP 20) não é algo exclusivo desta linguagem, mas é aplicável a qualquer uma, respeitando suas especificidades, evidentemente, a fim de se ter um bom design de código.
Mas vamos logo ao nosso prato principal.
🐣Easter Egg
Como uma filosofia, você deve trazer o Zen do Python para sua vida, importar para sua prática de codificação, simples assim:
>>> import this
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!
E aqui estão nossos princípios baseados nos mantras para um código Pythonico: Legível, Explícito e Simples. Boa parte destes pontos são auto explicativos, mas vamos abordar cada um.
Beautiful is better than ugly.
Logicamente, bonito é melhor que feio. Dentre os diversos caminhos que podemos ter para chegar a uma solução, escolha sempre o algoritmo mais bonito visualmente.
👿
if major(person) && not isNegative(person) || rich(person): return 'borrow money'
Explicit is better than implicit.
Por ser bastante flexível, você poderá ter diversas formas de chegar no seu objetivo, mas é bom que fique tudo bem claro, melhor dizendo, explícito, para quem ver aquele código entenda o que está sendo feito, sem deduções ou hipótese, seja parente aos olhos. Então não esconda partes do seu código.
Simple is better than complex.
Aqui está o ponto central, que liga os dois primeiros mantras, a simplicidade deve imperar. Não adianta ter um código bonito e explícito, se fica algo muito complexo, para isso um boa prática seria dividir em pequenos pedaços.
Complex is better than complicated.
Mas se a complexidade é inerente à sua solução, não deixe ela complicada, pois isto poupará dores de cabeça futuras. Siga design patterns e princípios como SOLID, DRY e KISS para ter algo complexo para execução, mas não complicado para manutenção.
Flat is better than nested.
As únicas pessoas que podem usar o hadouken é o Ryu e o Ken de Street Fighter, programadores NÃO! Como Python se utiliza de indentação para delimitar blocos de código, não aninhe muitas estruturas em outras estruturas, deixe o plano possível, próximo à esquerda.
Sparse is better than dense.
Não amontoe muito código em uma linha de código, porque bonito é melhor que feio.
👿
...
print('Reprovado') if nota < 5 else print('Recuperação') if nota <= 5 and nota < 7 else print('Aprovado')
😇
if nota < 5:
print('Reprovado')
elif nota <= 5 and nota < 7:
print('Recuperação')
elif nota >= 7:
print('Aprovado')
Readability counts.
Sempre tenha em mente que ninguém é oniciente para adivinhar o que você quer dizer com seu código, então justifique a razão da existência de cada variável, função e classe pela sua declaração, para melhor legibilidade.
👿
x = ['Maçã', 'Banana', 'Uva']
for z in x:
print(f'Comprar: {z}')
😇
lista_de_compras = ['Maçã', 'Banana', 'Uva']
for item in lista_de_compras:
print(f'Comprar: {item}')
Special cases aren’t special enough to break the rules. Although practicality beats purity.
Errors should never pass silently. Unless explicitly silenced.
Todas as falhas devem ser vistas, jamais ignoradas, por isso é importante tratá-las.
👿
try:
data_from_api = request_to_my_service(...)
...
except:
pass
😇
try:
data_from_api = request_to_my_service(...)
...
except RequestException as execption:
fail_handler(exception)
print(exception)
raise exception
In the face of ambiguity, refuse the temptation to guess.
Quando seu código expõe possibilidades de ocorrer erros antecedidos de certas condições, essas condições irão ser atendidas, e seu código irá se comportar de forma inesperada.
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.
Uma boa prática em Python é que você utilize apenas uma única solução bonita, simples e legível para seu problema. Isso é o que possibilita a facilidade em desenvolver softwares com essa linguagem. Se fosse mais difícil, ainda assim seria fácil, somente para Guido van Rossum, criador do Python (que é um Holandês).
Now is better than never. Although never is often better than right now.
Pensou em algo, execute agora. Conforme vai se aprimorando a ideia, ela ficará pythonicamente bonita.
If the implementation is hard to explain, it’s a bad idea.
Se a implementação da sua aplicação gerou dúvidas e não lhe agradou, pythonicamente, você deve revisá-la, a fim de alinhá-la com o Zen.
If the implementation is easy to explain, it may be a good idea.
O fato de ser uma ideia fácil de explicar, não resultará necessariamente em boa implementação.
Namespaces are one honking great idea—let’s do more of those!
Namespaces são uma forma de agregar componentes (objetos, classes, funções) relacionados a um mesmo contexto, permitindo a simplicidade e a legibilidade, por isso uma boa ideia.
😇
import entities.people as people
import entities.product as product
def buy(buyer: people.Person, item: product.Product):
return buyer.buy(item)
fruit = product.Product('Apple', '0.5')
person = people.Person('Alex Anderson')
print(buy(person, fruit))