Com inúmeras práticas recomendadas de Python circulando on-line, as opiniões sobre cada uma podem variar dependendo de a quem você pergunta. A Internet democratizou o conhecimento, permitindo que qualquer pessoa – inclusive eu – compartilhasse suas opiniões. No entanto, neste artigo, vamos nos concentrar em 10 práticas recomendadas atemporais do Python que alcançaram amplo consenso e são amplamente consideradas fundamentais.

Folha de referências do Pandas

Folha de dicas dos comandos do Git

As 50 principais perguntas da entrevista sobre SQL

Dica 1: as funções devem especificar o parâmetro e o tipo de retorno
Ao definir uma função, você deseja sempre especificar quais são os tipos dos argumentos e também qual tipo de dados o resultado da função retorna. Isso ajudaria você e os desenvolvedores de sua equipe a saber o que esperar, sem sempre ter que usar instruções de impressão para obter uma compreensão visual.

Dica 2: as funções devem estar no mesmo nível de abstração
Quando falamos que funções estão no mesmo nível de abstração, estamos nos referindo à ideia de que uma função deve realizar uma tarefa única e bem definida. Essa tarefa deve estar em um nível consistente de abstração em toda a função. Em outras palavras, a função deve focar em um nível específico de detalhe ou complexidade, e todas as operações das funções devem operar nesse mesmo nível.

Dica 3: as funções devem ser pequenas
Uma função deve ser reutilizável. E quanto maior fica a função, menor é a probabilidade de ela ser reutilizável. Isso também se correlaciona com o motivo pelo qual uma função deve fazer apenas uma coisa. Se fizer apenas uma coisa, há uma grande chance de ser pequeno.

Dica 4: princípios abertos e fechados
O princípio aberto-fechado (OCP) afirma que uma classe, método ou função deve ser aberta para extensão, mas não para modificação. Isso significa que qualquer classe, método ou função definida pode ser facilmente reutilizada ou estendida para múltiplas instâncias sem alterar seu código.
Isso falha em aderir ao OCP porque sempre que houver um novo país, precisaríamos escrever uma nova declaração if para complementá-la. Isto pode parecer simples agora, mas imagine que temos 100 ou mais países a ter em conta. Como seria isso?

Dica 5: evite comentários a todo custo
Os comentários costumam ser falsamente verdadeiros. Eles desviam a mente do leitor do que o código está realmente fazendo para o que outra pessoa diz que está fazendo.

Isso pode se tornar muito problemático conforme o tempo passa e o código recebe atualizações ou alterações. Em algum momento, o comentário se torna uma mentira e todos agora têm que observar a verdade através das lentes da mentira.

Comentários devem ser evitados a todo custo. Um comentário força o leitor a herdar o seu pensamento que, na melhor das hipóteses, está no passado. Quando uma função ou classe muda, provavelmente seus comentários não mudam junto com ela. Muito provavelmente, eles impedem o leitor de pensar no futuro.

Um comentário significa que o escritor foi mentalmente incapaz de fornecer uma classe, função ou nome de variável bem descritivo. Isso expõe a atitude sem brilho do programador e força a equipe a herdar tal atitude.

Dica 6: evite números mágicos
Um Número Mágico é um valor codificado que pode mudar posteriormente, mas que pode ser difícil de atualizar.

Por exemplo, digamos que você tenha uma página que exibe os últimos 50 pedidos em uma página de visão geral “Seus pedidos”. 50 é o Número Mágico aqui porque não é definido por padrão ou convenção, é um número que você criou pelos motivos descritos nas especificações.

Agora, o que você faz é ter os 50 em lugares diferentes - seu script SQL (SELECT TOP 50 * FROM pedidos), seu site (seus últimos 50 pedidos), seu login de pedido (para (i = 0; i

Dica 7: evite aninhamento profundo
Limite os níveis de aninhamento em loops, condicionais ou funções para melhorar a legibilidade.

Dica 8: evite caminhos de codificação
Evite codificar caminhos de arquivos ou URLs; use arquivos de configuração ou variáveis ​​de ambiente.

Dica 9: as turmas devem ser pequenas
Sim! As turmas devem ser tão pequenas quanto possível. Assim como as funções.

A única diferença é que nas funções, o tamanho é determinado pelo número de linhas nessa função, enquanto nas classes, é determinado pelo número de responsabilidades nessa classe.

Normalmente, o nome de uma classe representa o tipo de responsabilidades que ela pode possuir, mas quando o nome é ambíguo ou muito genérico, provavelmente estamos atribuindo responsabilidades demais a ele.

Isso nos leva de volta ao SRP (princípio de responsabilidade única), que afirma que uma classe deve ter apenas um motivo - uma responsabilidade - para mudar.

Dica 10: evite expressões ternárias complexas
Evite usar expressões ternárias excessivamente complexas; favoreça a legibilidade em vez da brevidade para tornar o código mais compreensível.