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

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:

— bhadra
fuente

14

Sigo las pautas de Python Idioms and Efficiency , de Rob Knight. Creo que son exactamente iguales a PEP 8, pero son más sintéticos y se basan en ejemplos.

Si está utilizando wxPython, es posible que también desee consultar la Guía de estilo para el código wxPython , de Chris Barker.

— Mapad
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