The Invent with Python Blog

The Zen of Python by Tim Peters are 20 guidelines for the design of the Python language. O seu código Python não tem necessariamente de seguir estas orientações, mas é bom ter em mente. O Zen de Python é um ovo de Páscoa, ou piada escondida, que aparece se você correr import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful 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!

nota: misteriosamente, apenas 19 das diretrizes são escritas. Guido van Rosum teria dito que o 20º aforismo desaparecido é ” uma piada bizarra de Tim Peters.”

no final, estas orientações são opiniões que podem ser argumentadas a favor ou contra. Como todos os bons conjuntos de códigos morais, às vezes se contradizem para proporcionar a maior flexibilidade. Aqui está a minha própria interpretação destes aforismos:

Bela é melhor do que feia.

programadores geralmente escrevem código rapidamente sem preocupação de legibilidade. Embora o código não tenha que ser legível, o código da linguagem Python em si deve ser pensado, consistente, e uma alegria de usar. É claro que nem todos os script precisam ser bonitos, e a beleza é subjetiva, mas grande parte da popularidade de Python é resultado de ser tão fácil de trabalhar.

explícito é melhor que implícito.”Este aforismo é auto-explicativo”, que seria uma terrível explicação para qualquer aforismo. Da mesma forma, é melhor que o código seja verbal e explícito. Você deve evitar esconder a funcionalidade do código por trás de funcionalidades obscuras da linguagem que requerem familiaridade para entender completamente.

simples é melhor que Complexo. Complexo é melhor que complicado.Estes dois aforismos lembram-nos que construir qualquer coisa pode ser feito usando técnicas simples ou complexas. Com um problema simples, como construir uma casa de pássaros, uma solução simples é melhor. Construir um motor diesel trem, por outro lado, é um problema complexo que requer técnicas complexas. Mesmo se você pudesse tecnicamente fazer um motor diesel de trem usando técnicas birdhouse, você provavelmente acabaria com um complicado, arranjo de Rube Goldberg de peças birdhouse que não seria uma solução ideal. Prefere simplicidade à complexidade, mas conhece os limites da simplicidade.

plano é melhor que aninhado.

os programadores adoram organizar as coisas em categorias, especialmente as categorias que contêm subcategorias que contêm outras subcategorias. Estas hierarquias muitas vezes não adicionam organização tanto quanto acrescentam burocracia. Não faz mal ter código em apenas um módulo de topo ou classe em vez de dividir-se em vários submódulos ou subclasses. Se você faz pacotes e módulos que requerem código como import spam.eggs.bacon.ham.foo.bar, então você está tornando o seu código muito complicado.

esparso é melhor que denso.

Programadores muitas vezes gostam de encaixar tanta funcionalidade em tão pouco Código quanto possível, tais como unit-liners como o seguinte: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

a legibilidade conta.

While strcmp() may obviously mean the “string compare” function to someone who has been programming in C since the 1970s, modern computers have enough memory to write out the full function name. Não largues as vogais dos teus nomes nem escrevas um código demasiado terse. O código é lido mais frequentemente do que é escrito, por isso o código legível e Explícito é mais importante do que o terse, código não codificado.Casos especiais não são especiais o suficiente para quebrar as regras. Embora a praticidade seja melhor que a pureza.Estes dois aforismos, que vêm como um conjunto, contradizem-se. A programação está cheia de” melhores práticas ” pelas quais os programadores devem se esforçar em seu código. Desviar estas práticas para uma invasão rápida pode ser tentador, mas pode levar a um ninho de ratos de código inconsistente e ilegível. No entanto, curvar-se para trás para aderir às regras pode resultar em código altamente abstrato e ilegível. A tentativa da linguagem de programação Java de ajustar todo o código ao seu paradigma orientado a objetos muitas vezes resulta em muitos códigos de boilerplate para até mesmo o menor programa. Caminhar na linha entre estes dois aforismos torna-se mais fácil com a experiência. E com o tempo, você não só aprenderá as regras, mas também aprenderá quando quebrá-las.

os erros nunca devem passar silenciosamente. A menos que explicitamente silenciado.

só porque os programadores muitas vezes ignoram mensagens de erro não significa que o programa deve parar de emiti-las. Erros silenciosos podem acontecer quando as funções retornam códigos de erro ou None em vez de levantar exceções. Estes dois aforismos nos dizem que é melhor para um programa para fail fast e crash do que para silenciar o erro e continuar executando o programa. Os bugs que inevitavelmente acontecem mais tarde serão mais difíceis de depurar, uma vez que eles estão longe da causa original. Embora você possa sempre optar por ignorar explicitamente os erros que seus programas causam, apenas certifique-se de que você está fazendo a escolha consciente para fazê-lo.

em face da ambiguidade, recuse a tentação de adivinhar.Os computadores tornaram os humanos supersticiosos: para exorcizar os demónios nos nossos computadores, executamos o ritual sagrado de desligá-los e depois ligá-los. Supostamente isto vai resolver qualquer problema misterioso. No entanto, os computadores não são mágicos. Se seu código não está funcionando, há uma razão e só o pensamento crítico e cuidadoso vai resolvê-lo. Recuse a tentação de tentar cegamente soluções até que algo parece funcionar; muitas vezes você apenas mascarou o problema em vez de resolvê-lo.

deve haver uma—e de preferência apenas uma-forma óbvia de o fazer.

este é um lado largo contra o lema da linguagem de programação Perl, ” há mais de uma maneira de fazê-lo!”Acontece que ter três ou quatro maneiras diferentes de escrever código que faz a mesma coisa é uma espada de dois gumes: você tem flexibilidade em como escrever código, mas agora você tem que aprender de todas as maneiras possíveis que ele poderia ter sido escrito para lê-lo. Esta flexibilidade não vale o esforço 3x ou 4x necessário para aprender uma linguagem de programação.

embora essa forma possa não ser óbvia no início, a menos que você seja Holandês.Esta linha é uma piada. Guido van Rossum, o criador e Bdfl (benevolente ditador vitalício) de Python, é Holandês. No entanto, nem mesmo este aforismo impediu Python de incorporar três formas diferentes de formatação de cadeias.

Now is better than never. Embora nunca seja melhor do que agora .

Estes dois aforismos dizem-nos que o código que trava ou fica preso em loops infinitos, obviamente, é pior do que o código que não. No entanto, é quase certamente melhor do que esperar para o seu programa para concluir que, para tê-lo terminar muito cedo com resultados incorretos.Se a implementação é difícil de explicar, é uma má ideia. Se a implementação for fácil de explicar, pode ser uma boa ideia.

Python esforça-se para tornar o trabalho do programador mais fácil ao invés de acomodar o computador para que um programa corra mais rápido. E os programas precisam ser compreensíveis não apenas pelo programador que os escreveu, mas também por outros programadores que mantêm o código. Estes dois aforismos nos lembram que se o código de” alto desempenho ” é tão complicado que é impossível para os programadores entenderem e depurarem, então é um código ruim. Mas, infelizmente, só porque é fácil explicar o código de um programa a outra pessoa não significa que não seja um código mau. A programação é difícil.

Namespaces are one honking great idea-let’s do more of those!

Namespaces (and also global and local scopes) are key for preventing names in one module or scope from conflicting with names in another. Mas também lembre-se que flat é melhor do que aninhado: por muito grandes que sejam, os espaços de nomes devem ser feitos apenas para prevenir conflitos de nome, e não para adicionar categorização desnecessária.

como todas as opiniões sobre programação, as que escrevi aqui podem ser contestadas ou podem simplesmente ser irrelevantes para a sua situação. Discutir sobre como o código deve ser escrito raramente é tão produtivo quanto você pensa que é. A não ser que estejas a escrever um livro cheio de opiniões de programação.)