Zen é uma coleção de princípios orientadores - quase que na forma de poema - com uma série de aforismos, para escrever programas de computador que influenciam o design da linguagem.

É necessário dizer que a maioria dos zens descritos aqui foram amontoados que encontrei falando sobre o tema, mas que as devidas linguagens não tem claridade sobre estes assuntos, ou até mesmo existem longas discussões falando se vale a pena ter zen ou não e se listar os valores fundamentais da linguagem pode ou não limitar a sua evolução. Mas, o que você acha sobre essa pauta?

De qualquer maneira, vamos para a lista de conceitos fundamentais em forma quase que poética ou até mesmo princípios guias das linguagens mais conhecidas de mercado! (Lembrando que alguns termos não são oficiais da própria linguagem, mas sim comentários obtidos a partir das referências ao final deste artigo).

Zen do Python

Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor do que complicado.
Plano é melhor do que aninhado.
Esparso é melhor do que denso.
A legibilidade conta.
Casos especiais não são especiais o suficiente para quebrar as regras.
Embora a praticidade supere a pureza.
Os erros nunca devem passar silenciosamente.
A menos que explicitamente silenciado.
Diante da ambiguidade, recuse a tentação de adivinhar.
Deve haver uma - e de preferência apenas uma - maneira óbvia de fazer isso.
Embora essa maneira possa não ser óbvia no início, a menos que você seja holandês.
Agora é melhor do que nunca.
Embora nunca seja melhor do que agora.
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.
Namespaces são uma ótima ideia -- vamos fazer mais desses!

Zen do Zig

Comunique a intenção com precisão.
Casos de borda importam.
Favorecer a leitura de código sobre a escrita de código.
Apenas uma maneira óbvia de fazer as coisas.
Falhas em tempo de execução são melhores que bugs.
Erros de compilação são melhores do que falhas de tempo de execução.
Melhorias incrementais.
Evite máximos locais.
Reduza a quantidade que se deve lembrar.
Concentre-se no código e não no estilo.
A alocação de recursos pode falhar; a desalocação de recursos deve ser bem-sucedida.
A memória é um recurso.
Juntos atendemos os usuários.

Zen do JavaScript

Construir funcionalidade, não arquitetura.
Construa pequenas coisas que funcionam
e colá-los juntos para fazer coisas grandes.
Claro é melhor do que inteligente,
mas graciosa supera ambos.
Comentários são bons, mesmo se você for holandês.
Assíncrono é melhor que síncrono
exceto quando não é
mas seu código deve funcionar em ambos.
Convenção é melhor que definição,
se você tiver bons documentos.
Mantenha-o solto, mas construa bons testes.

Zen do Rust

Performance.
Confiabilidade.
Produtividade.
Aplicabilidade.
Força.
Dependência de contexto.
Sem mágica, apenas código.
Evitar código inseguro. Na falta disso, encapsule-o.
Segurança importa.
Não explícito.
Explícito não é barulhento.
Explícito não é pesado.
Explícito não é manual.
Explícito não é local.
Rust é explícito porque você pode descobrir muito sobre seu programa a partir da fonte dele.
Uma linguagem que capacita todos a criar software confiável e eficiente.

Zen do Java

A verbosidade túrgida é melhor do que a brevidade.
Múltiplas linhas de código são melhores do que simplicidade concisa.
As técnicas de software de meados da década de 1980 são melhores do que a tecnologia adaptável moderna.
Muitas bibliotecas legadas são melhores do que uma organização limpa.
Desenvolvimento lento e caro com grande sobrecarga é melhor do que agilidade.
explicit.compareTo(implicit) == 1
Frameworks sobre bibliotecas.
Os sistemas de construção devem ser enigmáticos e verbosos.
Uma equipe é mais importante do que um indivíduo.
As construções de linguagem que explicam os efeitos colaterais são desaprovadas (exceções verificadas).
Você ficará surpreso com o quão longe pode ir antes de obter um código compatível com OO que faça o que você precisa. Muito, muito longe…
A complexidade acidental é indistinguível da complexidade inerente.
Se algumas de suas classes não têm estado, ou não associam comportamento a ele, ou não transformam esse estado com esse comportamento, então por que usar Java?
Um campo sem um par getter/setter é um desperdício de espaço.
Os sistemas escritos em Java devem consistir em Handlers, Controllers, Managers, Services, Components, Helpers, Utils, Converters, Factories, Proxies, Pools (e combinações destes) operando Data, Infos, Items, Nodes, Models, Containers, Wrappers (e combinações) e coleções desses.
Nirvana é onde todos os métodos têm zero argumentos porque todas as dependências são injetadas.

Zen do Go

Cada pacote cumpre um único propósito.
Lidar com erros explicitamente.
Retornar cedo ao invés de nidificar profundamente.
Deixe a concorrência para o requisitante.
Antes de iniciar uma goroutine, saiba quando ela irá parar.
Evite o estado do nível do pacote.
Simplicidade importa.
Escreva testes para bloquear o comportamento da API do seu pacote.
Se você acha que é lento, primeiro prove com um benchmark.
Moderação é uma virtude.
Manutenibilidade conta.

Zen do C#

Evite funções impuras, prefira funções puras.
Evite objetos mutáveis.
Evite funções opacas, prefira funções transparentes.
Evite lambdas obscuras, prefira funções nomeadas.
Evite chamadas procedurais das funções (quando aplicável), prefira chamadas dinâmicas das funções (onde aplicável).

Zen do PHP

Rápido.
Flexível.
Pragmático.
PHP é um acrônimo para "PHP: Hypertext Preprocessor"
O código PHP é executado no servidor.
PHP é uma linguagem de script de código aberto amplamente utilizada.
O PHP é gratuito para baixar e usar.
PHP é uma linguagem incrível e popular!
É poderoso o suficiente para estar no centro do maior sistema de blogging da web (WordPress)!
É profundo o suficiente para executar grandes redes sociais!
Também é fácil ser a primeira linguagem de servidor para iniciantes!

Zen do C++

Expresse ideias diretamente no código.
Escreva em ISO padrão C++.
Intenção expressa.
Idealmente, um programa deve ser estaticamente seguro.
Prefira a verificação em tempo de compilação à verificação em tempo de execução.
O que não pode ser verificado em tempo de compilação deve ser verificado em tempo de execução.
Detecte erros de tempo de execução com antecedência.
Não vaze nenhum recurso.
Não perca tempo nem espaço.
Prefira dados imutáveis a dados mutáveis.
Não muito feio é melhor do que muito feio.
Explícito é melhor que implícito, mas padrões ruins são piores que ambos.
Uma implementação simples é melhor do que uma complicada.
Uma implementação complicada é melhor do que uma interface complexa.
Contíguo é melhor do que busca por ponteiro.
A busca por ponteiro é melhor do que a busca por ponteiro duplo.
A legibilidade é importante; então C++ sendo o que é, escreva muitos comentários.
Casos especiais exigirão quebrar as regras, mas tente manter a quebra de regra oculta.
Dito isso, se você não pode esconder a quebra de regra, uma solução impura prática para um problema menor é melhor do que uma solução impraticável pura para o problema genérico.
Não use códigos de erro.
A menos que sua verificação seja aplicada estaticamente.
Diante da ambiguidade, não compile.
Haverá muitas maneiras de fazer tudo; conheça seus trade-offs e seja um engenheiro e escolha um!
Embora a maneira mais limpa e sustentável não seja óbvia a princípio, a menos que você leia livros e assista a palestras de muitas pessoas realmente inteligentes.
2011 está melhor do que nunca.
Embora nunca possa ser melhor se você não tiver pensado nisso.
Se a interface causa facilmente um comportamento indefinido, é uma má ideia.
Se a implementação for segura, pode ser uma boa ideia.
Const é uma ótima ideia, use-a em todos os lugares que puder!
Não declare retorno const por valor. Isso é rude.
Não declare locais de função const se você pretende retorná-los ou movê-los (const inibe a movimentação).
Use os membros de dados não estáticos const criteriosamente, eles desativam os operadores de atribuição e (novamente) inibem o movimento.
Você não paga pelo que não usa.
Não deixe um requisito para alguma outra linguagem que forneça um nível inferior de abstração (acesso mais direto ao hardware).
Penalidades por abstração devem ser minimizadas.
A sintaxe feia pode ser aceitável se desencorajar construções de propósito especial (por exemplo, reinterpet_cast).
Resolver um problema geral é melhor do que resolver um específico.
É melhor prevenir problemas do que resolvê-los.
Os erros devem ser detectados o mais cedo possível.
Série de livros de Scott Meyers Effective C++.
C++ Moderno por Alexander Alexandrescu.
Favorecer tipos de dados STL em vez de tipos C simples.
Apenas vá para a codificação de estilo C após a criação de perfil, se realmente for importante.
Sempre compile com avisos como erros, no nível máximo.
Faça uso da análise estática.

Zen do Ruby

A beleza está nos olhos de quem vê.
Implícito é preferível ao explícito.
Simples é chato.
Complexo é interessante.
Delegue os detalhes a outra pessoa.
Se possível, faça um one-liner.
A legibilidade às vezes é boa.
Casos especiais estão por toda parte; as regras não podem abranger todos eles.
Em caso de dúvida, monkeypatch.
Os erros devem ser suprimidos.
A menos que nils chorosos estejam ativados.
Em caso de dúvida, faça suposições sobre o que o usuário queria.
Deve haver muitas - de preferência dezenas - de maneiras não óbvias de fazer isso.
O que é óbvio para você pode não ser intuitivo para outra pessoa.
Agora é melhor do que tarde.
E tarde é melhor do que nunca.
Se o design for falho, explique o motivo nos documentos de implementação.
Se o design for bom, não se preocupe com os documentos de implementação.
Namespaces são completamente desnecessários -- vamos tornar tudo global!

Zen do Perl

A beleza é subjetiva.
Explícito é recomendado, mas não obrigatório.
Simples é bom, mas complexo também pode ser bom.
E embora complicado seja ruim,
Verboso e complicado é pior.
Breve é melhor do que verboso.
Mas a legibilidade conta.
Portanto, use espaços em branco para melhorar a legibilidade.
Não porque você é obrigado.
A praticidade sempre supera a pureza.
Diante da ambigüidade, faça o que quero dizer.
Há mais de uma maneira de fazer isso.
Embora isso possa não ser óbvio, a menos que você seja um monge.
A seu critério é melhor do que nada.
Embora seu critério deva ser usado criteriosamente.
Só porque o código parece limpo não significa que seja bom.
Só porque o código parece confuso não significa que seja ruim.
A reutilização via CPAN é uma ótima ideia -- vamos fazer mais disso!

Zen do Zen

Linguagem de programação de propósito geral.
Projetado para construir programas simples, confiáveis e eficientes.
Sintaxe clara.
Fácil de aprender e usar.
Com uma combinação de bibliotecas, torna tarefas como manipulação de strings, cálculos matemáticos, redes e outras tarefas mundanas extremamente simples.
Simples.
Dinamicamente tipada.
Tempo de compilação rápido.

Chamada para a Ação

Deixe seu comentário falando sobre algum destes zens, se você conhece o zen oficial da sua linguagem favorita ou conhece algo que poderia agregar para entendermos melhor quais decisões foram tomadas para a evolução de determinada linguagem. Muito obrigado por ler o artigo até aqui! 😁

Compilado: Zen dos Zens - Zens Conhecidos e Outros Nem Tanto Assim