Estándares de codificación Python / mejores prácticas [cerrado]

116

En Python, ¿generalmente usa PEP 8 - Guía de estilo para código Python como sus estándares / pautas de codificación? ¿Existen otros estándares formalizados que prefiera?

python coding-style Kozyarchuk
fuente
1
//, La solicitud de "preferencias de la audiencia" puede parecer inofensiva, al principio, pero convierte el stackoverflow en un mecanismo de votación, una especie de democracia pervertida de unos pocos contra muchos. "¿Hay algún otro ________ que prefieras?" es, literalmente, pedirles una preferencia, no un hecho.
Nathan Basanese

Respuestas:

150

"En Python, ¿generalmente utiliza PEP 8 - Guía de estilo para código Python como sus estándares / pautas de codificación? ¿Hay otros estándares formalizados que prefiera?"

Como mencionaste, sigue PEP 8 para el texto principal y PEP 257 para las convenciones de cadenas de documentos

Junto con las Guías de estilo de Python, le sugiero que consulte lo siguiente:

  1. Codifique como un Pythonista: Python idiomático
  2. Errores comunes y verrugas
  3. Cómo no escribir código Python
  4. Python te tengo
bhadra
fuente
8

Me atengo a PEP-8 muy de cerca.

Hay tres cosas específicas que no puedo molestarme en cambiar a PEP-8.

  • Evite los espacios en blanco extraños inmediatamente entre paréntesis, corchetes o llaves.

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

    Hago esto de todos modos: spam( ham[ 1 ], { eggs: 2 } )

    ¿Por qué? Más de 30 años de hábito arraigado es acurrucarse () contra nombres de funciones o palabras clave de declaraciones (en C). Comenzando con Fortran IV en los años 70.

  • Utilice espacios alrededor de los operadores aritméticos:

    Sugirió: x = x * 2 - 1

    Hago esto de todos modos: x= x * 2 - 1

    ¿Por qué? The Science of Programming de Gries sugirió esto como una forma de enfatizar la conexión entre la asignación y la variable cuyo estado se está cambiando.

    No funciona bien para asignaciones múltiples o asignaciones aumentadas, para eso utilizo muchos espacios.

  • Para nombres de funciones, nombres de métodos y nombres de variables de instancia

    Se sugiere: minúsculas, con palabras separadas por guiones bajos según sea necesario para mejorar la legibilidad.

    Hago esto de todos modos: camelCase

    ¿Por qué? Más de 20 años de arraigado hábito de camelCase, comenzando con Pascal en los años 80.

S. Lot
fuente
1
¡Eso es un gran contenido! codingstyleguide.com o codereview.stackexchange.com sería un buen lugar para tener estas excelentes pautas.
Pompeyo
5

PEP 8 es bueno, lo único que desearía que fuera más difícil fue la guerra santa Tabs-vs-Spaces.

Básicamente, si está comenzando un proyecto en Python, debe elegir Tabs o Spaces y luego disparar a todos los infractores a la vista.

Ryan
fuente
4
¿Pestañas o espacios? De PEP8: Los espacios son el método de sangría preferido. Las pestañas deben usarse únicamente para mantener la coherencia con el código que ya está sangrado con pestañas.
The Demz
//, PEP8 tiene bastante claro que los espacios son el método de sangría preferido, Ryan. Voto en contra. Sin embargo, ¿actualizaría la respuesta?
Nathan Basanese
5

Para agregar a la lista de guías idiomáticas de bhadra :

Consulte la presentación de Anthony Baxter sobre la programación eficaz de Python (de OSON 2005).

Un experto:

# 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
fuente
4

Lo sigo con mucho rigor. El único dios antes de PEP-8 son las bases de código existentes.

Alex Gaynor
fuente
1
y me gustaría señalar que PEP-8 incluso tiene en cuenta las bases de código existentes.
John Mulder
2

Sí, trato de seguirlo lo más de cerca posible.

No sigo ningún otro estándar de codificación.

Oli
fuente
1

Sigo el PEP8, es una gran pieza de estilo de codificación.

feliz
fuente