Padrões / práticas recomendadas de codificação Python [fechado]

116

Em Python, você geralmente usa PEP 8 - Guia de Estilo para Código Python como seus padrões / diretrizes de codificação? Existem outros padrões formalizados de sua preferência?

python coding-style Kozyarchuk
fonte
1
//, A solicitação de "preferências do público" pode parecer inofensiva, a princípio, mas transforma o stackoverflow em um mecanismo de votação, uma espécie de democracia pervertida de poucos contra muitos. "Existe algum outro ________ que você prefere?" é, literalmente, pedir-lhes uma preferência, não um fato.
Nathan Basanese de

Respostas:

150

"Em Python, você geralmente usa PEP 8 - Guia de Estilo para Código Python como seus padrões / diretrizes de codificação? Há algum outro padrão formalizado de sua preferência?"

Conforme mencionado por você, siga o PEP 8 para o texto principal, e o PEP 257 para as convenções de docstring

Junto com os guias de estilo Python, sugiro que você consulte o seguinte:

  1. Código como um Pythonista: Python idiomático
  2. Erros e verrugas comuns
  3. Como não escrever código Python
  4. Python pegou
bhadra
fonte
8

Eu me apego ao PEP-8 muito de perto.

Existem três coisas específicas que não posso me incomodar em mudar para PEP-8.

  • Evite espaços em branco estranhos imediatamente entre parênteses, colchetes ou colchetes.

    Sugerido: spam(ham[1], {eggs: 2})

    Eu faço isso mesmo assim: spam( ham[ 1 ], { eggs: 2 } )

    Por quê? Mais de 30 anos de hábitos arraigados estão se aconchegando () contra nomes de funções ou palavras-chave de declarações (em C). Começando com Fortran IV nos anos 70.

  • Use espaços ao redor dos operadores aritméticos:

    Sugerido: x = x * 2 - 1

    Eu faço isso mesmo assim: x= x * 2 - 1

    Por quê? A ciência da programação de Gries sugeriu isso como uma forma de enfatizar a conexão entre a atribuição e a variável cujo estado está sendo alterado.

    Não funciona bem para tarefas múltiplas ou tarefas aumentadas, para isso eu uso muitos espaços.

  • Para nomes de funções, nomes de métodos e nomes de variáveis ​​de instância

    Sugerido: letras minúsculas, com palavras separadas por sublinhados conforme necessário para melhorar a legibilidade.

    Eu faço isso mesmo assim: camelCase

    Por quê? Mais de 20 anos de hábito enraizado de camelCase, começando com Pascal nos anos 80.

S.Lott
fonte
1
Esse é um ótimo conteúdo! codingstyleguide.com ou codereview.stackexchange.com seria um bom lugar para ter essas ótimas diretrizes.
Pompeyo
5

PEP 8 é bom, a única coisa que eu gostaria que fosse mais difícil seria a guerra santa Tabs-vs-Spaces.

Basicamente, se você está iniciando um projeto em python, você precisa escolher guias ou espaços e atirar em todos os criminosos à vista.

Ryan
fonte
4
Guias ou espaços? Do PEP8: Espaços são o método de indentação preferido. As guias devem ser usadas exclusivamente para permanecer consistentes com o código que já está indentado com guias.
O Demz de
//, PEP8 deixa bem claro que os espaços são o método de indentação preferido, Ryan. Votos negados. Mas você atualizaria a resposta?
Nathan Basanese de
5

Para adicionar ao de bhadra lista de guias idiomáticos da :

Confira a apresentação de Anthony Baxter em Confira Programação Efetiva de Python (de OSON 2005).

Um trecho:

# dict's setdefault method turns this:
if key in dictobj:
    dictobj[key].append(val)
else:
    dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)
Ryan Cox
fonte
4

Eu o sigo com extremo rigor. O único deus antes do PEP-8 são as bases de código existentes.

Alex Gaynor
fonte
1
e eu observaria que o PEP-8 leva em consideração as bases de código existentes.
John Mulder
2

Sim, tento seguir o mais de perto possível.

Eu não sigo nenhum outro padrão de codificação.

Oli
fonte
1

Eu sigo o PEP8, é um ótimo estilo de codificação.

infeliz
fonte