O mundo está do avesso… temos uma pandemia acontecendo, todos estão vivendo um dia por vez. Para completar, temos um governo ruindo, basicamente por causa de patacoada atrás de patacoada. 

Esses assuntos dominam a pauta dos noticiários e, infelizmente, acabam invadindo ambientes que costumam ser agradáveis. Isso acontece porque estes fatos mexem com as emoções do cidadão. 

E o que pode sair de discussões apaixonadas? Exatamente o que esses crápulas querem: Falta de foco no que realmente importa, além de pessoas semelhantes brigando entre si por só conseguir enxergar suas diferenças. 

Eu estou bem de saco cheio disso. Já que esses abutres não fazem nada para nos ajudar, não vou permitir que eles me atrapalhem mais do que já atrapalham.

Inspirado pelo excelente post do Ícaro de Carvalho, resolvi ignorar todo esse show de horror e trabalhar. Por isso, hoje quero falar de um assunto relativamente técnico. Você já ouviu falar sobre as maravilhas do Python? Hoje vou te provar porque Python é a MELHOR linguagem para você aprender.

Você conhece o Zen do Python?

Na semana retrasada o Renzo realizou a Semana do Programador Profissional. Foram 4 dias intensos ensinando as maravilhas do Python para pessoas interessadas em se tornarem profissionais de tecnologia.

Durante a SPP o Renzo fez o famoso “import this”, que mostra o Zen do Python, escrito por Tim Peters. Eu, com 10 anos de programação em Python, já conhecia o Zen do Python mas, por incrível que pareça, não sabia (ou pelo menos não lembrava) desse easter egg que o printava na tela.

O Zen do Python é um guia de estilo para o seu código Python. Assim como a PEP8, seu uso não é obrigatório, mas recomendado. Assim como todo código, seu objetivo é disponibilizar uma série de recomendações que te orientem, com o objetivo de atingirmos consistência.

Segundo o próprio Guido, criador da linguagem, código é muito mais lido do que escrito. Sendo assim, faz muito mais sentido despejar atenção em escrever um código que seja legível.

Um software é um organismo vivo. A partir do momento que o código entra em produção, ele se torna um código legado que, provavelmente, deverá ser revisitado no futuro, por você ou por outra pessoa (que não estava dentro da sua cabeça no momento que o código nasceu). O seu eu do futuro ficará grato pelo fato de, hoje, você escrever um código mais legível.

Vamos dar uma olhada nas “20” orientações do Zen of Python?

Bonito é melhor que feio (beautiful is better than ugly).

Cabe um post apenas sobre esse tópico. Se você fatalmente terá que ler seu código no futuro, você prefere ler algo bonito, elegante e bem feito, ou algo feio? 

Por favor, assista o documentário Why Beauty Matters, do grande Roger Scruton.

Explícito é melhor que implícito (explicit is better than implicit).

Uma comunicação flui de forma mais simples quando seus interlocutores se comunicam de forma simples, direta e explícita. Com código também funciona assim.

O que é mais fácil: bater o olho em um trecho de código e entender exatamente o que ele faz, ou precisar fazer uma análise minuciosa do que cada linha faz para conseguir entender o código como um todo?

Simples é melhor que complexo (simple is better than complex).

Ainda na linha do trecho anterior, uma comunicação simples facilita o entendimento de ambas as partes.

Neste momento estou discorrendo sobre os aforismos presentes na prescrição redigida com o objetivo de abrandar suas futuras interpretações linguísticas. Entendeu? Não? Vou colocar diferente. 

Agora estou escrevendo sobre um guia que vai te ajudar quando você for tentar compreender o código que escreveu. Mais fácil, né?

Complexo é melhor que complicado (complex is better than complicated).

Infelizmente, às vezes não podemos fugir do complexo. Problemas complexos geralmente exigem resoluções complexas. Isso não significa que você precisa complicar.

É perfeitamente possível implementar soluções complexas, mas que sejam simples de serem interpretadas.

Plano é melhor que encadeado (flat is better than nested).

O programador, via de regra, é uma pessoa lógica e analítica. Isso resulta em uma busca na necessidade de separar, categorizar e organizar as coisas. Quando isso é feito de maneira estratégica, o resultado é positivo. Mas quando feito de maneira displicente, o resultado é simplesmente mais burocracia.

Espaçado é melhor que denso (sparse is better than dense).

Se tem uma coisa que todo programador gosta é de otimização. Em especial as precoces. “Para que eu vou escrever uma linha a mais só para somar este número, sendo que eu posso somá-lo no momento que for exibir em tela?” 

Clássico, né? Ainda mais se for para impressionar os amigos. Agora, imagine aquele colega de trabalho que nunca encostou neste código. Quanto tempo ele vai demorar para descobrir onde ocorre a soma?

Legibilidade conta (readability counts).

Eu poderia dizer que este ítem se explica por si só, porém eu estaria sendo implícito. Como explícito é melhor que implícito, vou explicar.

Você, no calor da emoção, pode entender que uma função cpimg signifique copy_image. Será que seu colega, ou você daqui 6 meses, vai entender? E uma variável chamada items e contém uma lista de pedidos, não seria mais legível se chamasse items_of_orders?

Casos especiais não são especiais o suficiente para quebrar as regras (special cases aren’t special enough to break the rules).

Imagine que seu software possui um alto nível de desacoplamento e as responsabilidades de cada trecho de código estão muito bem limitadas e definidas. De repente, o sistema em produção caiu por causa de um bug. Você precisa corrigir este bug rápido, então acaba criando um trecho de código que mistura responsabilidade com outro. 

Quantas vezes o sistema em produção cai? Poucas? Se sim, vale a pena minar a qualidade do seu código por isso? Se cai muitas, será que a qualidade do código não está diretamente envolvida neste problema?

Embora praticidade supere pureza (although practicality beats purity).

Seguindo como uma continuação da orientação anterior, precisamos também lembrar que código é o meio de atingir um objetivo, e não possui um fim em si. 

No fim do dia, o nosso objetivo principal é entregar software funcionando para resolver o problema do nosso cliente. Escrever um bom código deve ajudar a alcançar este objetivo o mais rápido possível, não atrapalhar.

Erros nunca devem passar despercebidos (errors should never pass silently) a menos que ele seja explicitamente silenciado (unless explicitly silenced).

A minha experiência de vida me diz que sempre que escolhemos não dar atenção a um pequeno erro, ele voltará maior no futuro. Com erros de código isso não é diferente.

Por mais que um erro não interfira diretamente no bom funcionamento do software, ele deve ser registrado e conhecido.

Frente a uma ambiguidade, resista a tentação de adivinhar (in the face of ambiguity, refuse the temptation to guess).

Sabe quando a sua internet está uma merda, ou então quando o seu computador está apresentando um comportamento estranho, e o suporte fala para tirar o equipamento da tomada, aguardar 5 minutos e ligar novamente? Sim, ele não tem a mínima ideia do que está acontecendo e simplesmente decidiu restaurar as configurações padrões do sistema. 

Porém o problema pode continuar lá e, como já vimos anteriormente, sabemos que problemas renegados sempre voltam maiores.

Deve-se haver um – e preferencialmente somente um – modo óbvio de se fazer isso (there should be one– and preferably only one –obvious way to do it).

Python é uma linguagem flexível e poderosa a ponto de te garantir a possibilidade de resolver um mesmo problema de diversas maneiras possíveis. Isso é bom, pois te garante agilidade, mas ao mesmo tempo é ruim.

Ao adotarmos várias formas de resolver o mesmo problema, perdemos a padronização. Ao perder padronização, dificultamos o entendimento. Ao dificultar entendimento, diminuímos a capacidade de manutenção, e com isso, qualidade de código.

Embora este caminho possa não ser tão óbvio, a menos que você seja holandês (although that way may not be obvious at first unless you’re Dutch).

Isso é uma piada. O próprio Guido cometeu algumas falhas de design, como por exemplo, permitir 3 formas distintas de implementar uma string. Guido é holandês.

Agora é melhor que nunca (now is better than never), embora nunca seja melhor do que *exatamente* agora (although never is often better than *right* now).

Se você pode escrever um código melhor agora, porque não escrever, e, com isso, acumular mais um débito técnico que nunca será resolvido?

Ao mesmo tempo, é preciso termos cuidado para não exagerar e resolver problemas que ainda não existem e, provavelmente, nunca irão existir.

Se uma implementação é difícil de explicar, é uma má ideia (if the implementation is hard to explain, it’s a bad idea). Se uma implementação é fácil de explicar, provavelmente é uma boa ideia (if the implementation is easy to explain, it may be a good idea).

Se você não consegue nem explicar sua implementação, como acha que outros desenvolvedores conseguirão entendê-la? 

Namespaces são uma puta boa ideia — Vamos ter mais delas (namespaces are one honking great idea — let’s do more of those)!

Namespaces, no Python, possuem o poder de trazer contexto ao seu código. Se usado com inteligência, pode facilitar a implementação de todas estas outras orientações.

E ai, sua linguagem tem isso?

Essa preocupação com manutenção é mais um dos ítens que me fazer gostar tanto de Python a ponto de utilizá-la pelos últimos 10 anos.

Como disse anteriormente, e também em diversas outras vezes, nosso objetivo como programador é gerar valor. Escrever um bom código é premissa para isso, afinal, softwares são seres vivos que precisam de cuidados e manutenções periódicas. 

De forma genial, o Guido entendeu isso e focou seus esforços em construir uma linguagem que priorizasse o programador, ao invés da performance, afinal, nem todo sistema precisa de alta performance, mas todo sistema precisa de manutenção.