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

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?

"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

Eu sigo as regras de expressão e eficiência do Python , de Rob Knight. Acho que são exatamente iguais ao PEP 8, mas são mais sintéticos e baseados em exemplos.

Se você estiver usando wxPython, você também pode querer verificar o Guia de Estilo para o código wxPython , de Chris Barker.

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.

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.

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)

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

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

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

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