¿Estilo de codificación común para Python?

Question

Soy bastante nuevo en Python, y quiero desarrollar mi primer proyecto serio de código abierto. Quiero preguntar cuál es el estilo de codificación común para los proyectos de Python. Pondré también lo que estoy haciendo en este momento.

1.- ¿Cuál es el ancho de columna más utilizado? (la pregunta eterna)
Actualmente estoy apegándome a 80 columnas (y es un dolor!)

2.- ¿Qué comillas usar? (He visto todo y PEP 8 no menciona nada claro)
Estoy usando comillas simples para todo excepto docstrings, que usan comillas dobles triples.

3.- ¿Dónde pongo mis importaciones?
Los pondré en el encabezado del archivo en este orden.

import sys 
import -rest of python modules needed- 

import whatever 
import -rest of application modules- 

<code here> 

4.- ¿Puedo usar "whatever.function importación como bla"?
Vi algunos documentos que hacen caso omiso de hacer esto.

5.- ¿Tabs o espacios para sangría?
Actualmente usa pestañas de 4 espacios.

6.- ¿Estilo de nomenclatura variable? Estoy usando minúsculas para todo excepto las clases, que incluí en camelCase.

¿Algo que recomendarías?

Answer 1

PEP 8 es prácticamente la "raíz" de todas las guías de estilo comunes. El Python style guide de Google tiene algunas partes que son bastante bien pensadas, pero otras son idiosincrásicas (las sangrías de dos espacios en lugar de las populares de cuatro espacios, y el estilo de CamelCase para funciones y métodos en lugar del estilo camel_case, son idiosincrasias bastante importantes).

En a sus preguntas específicas:

1.- ¿Cuál es el ancho de la columna más utilizado? (La pregunta eterna) momento me quedo con 80 columnas (y es un dolor!)

80 columnas es más popular

2.- Lo que cita a utilizar? (He visto todo y PEP 8 no menciona nada claro) Estoy usando citas simples para todo excepto docstrings, que usan comillas dobles triples.

prefiero el estilo que está utilizando, pero incluso Google no era capaz de llegar a un consenso sobre este :-(

3.- ¿Dónde pongo mis importaciones? Estoy poniendo ellos en el encabezado del archivo en este orden .

import sys importar -Resto del pitón módulos solicitado-

importación sea cual sea la importación -Resto aplicación Modules-

Sí, una excelente elección, y también muy populares.

4.- ¿Puedo usar "import whatever.function as blah"? Vi algunos documentos que no hacen esto.

Le recomiendo que siempre importe módulos, no nombres específicos desde el interior de un módulo. Esto no es solo estilo, hay grandes ventajas, por ej. en la capacidad de prueba al hacer eso. La cláusula as está bien, para acortar el nombre de un módulo o evitar conflictos.

5.- ¿Tabs o espacios para sangría? Actualmente usa pestañas de 4 espacios.

La más popular.

6.- ¿Estilo de nombre variable? Estoy usando minúsculas para todo menos para las clases, que puse en camelCase.

Casi todo el mundo nombra las clases con mayúsculas inicial y constantes con letras mayúsculas.

Answer 2

1.- La mayoría de las personas tiene un monitor de 16: 9 o 16:10 ahora. Incluso si no tienen una pantalla panorámica, tienen muchos píxeles, 80 cols no es un gran obstáculo práctico como lo era cuando todos pirateaban en la línea de comandos en una ventana de terminal remota en un monitor 4: 3 en 320 X 240. Suelo terminar la línea cuando es demasiado larga, lo cual es subjetivo. Estoy en 2048 X 1152 en un monitor de 23 "X 2.

2.- Comillas simples por defecto para que no tenga que escapar Comillas dobles, Comillas dobles cuando necesite incrustar comillas simples, y Comillas triples para cuerdas con saltos de línea empotrados.

3.- Póngalos en la parte superior del archivo, a veces se los pone en el función principal si no se necesitan a nivel mundial para el módulo.

4.- es un idioma común para cambiar el nombre de algunos módulos. Un buen ejemplo es el siguiente.

try: 
    # for Python 2.6.x 
    import json 
except ImportError: 
    # for previous Pythons 
    try: 
     import simplejson as json 
    except ImportError: 
     sys.exit('easy_install simplejson') 

pero la forma preferida para importar sólo una clase o función es from module import xxx con el programa opcional as yyy si es necesario

5.- Siempre use ESPACIOS! 2 o 4 siempre que no TABS

6.- Las clases deben subir UpperCaseCamelStyle, las variables son minúsculas a veces lowerCamelCase o, a veces all_lowecase_separated_by_underscores, como son los nombres de funciones. "Constantes" debe ser ALL_UPPER_CASE_SEPARATED_BY_UNDERSCORES

En caso de duda, consulte PEP 8, la fuente de Python, las convenciones existentes en una base de código.Pero lo más importante es ser internamente consistente como sea posible. Todo el código de Python debería parecer escrito por la misma persona siempre que sea posible.

Answer 3

Como estoy realmente loco por el "estilo" escribiré las pautas que utilizo actualmente en un proyecto SLOC de casi 8k con aproximadamente 35 archivos, la mayoría coincide con PEP8.

1. PEP8 dice 79 (WTF?), Voy con 80 y yo estoy acostumbrado a ello ahora. Menos movimiento de los ojos después de todo!

2. Cadenas de documentos y cosas que abarca varias líneas en '' '. Todo lo demás en ''. Además, no me gustan las comillas dobles, solo uso comillas simples todo el tiempo ... supongo que es porque vine desde la esquina de JavaScript, donde es más fácil usar también '', porque de esa manera no tienes que escapar de todo el material HTML: O

3. En la cabecera, incorporado antes del código de la aplicación personalizada. Pero también utilizo un enfoque de "falla temprana", así que si hay algo de lo que depende la versión (GTK, por ejemplo) lo importaría primero.

4. Depende, la mayoría de las veces voy con import foo y de importación foo, pero hay algunos casos (por ejemplo, el nombre ya está definido por otra importación) cuando uso la barra de importación de foo como bla también.

5. 4 espacios. Período. Si realmente desea utilizar pestañas, asegúrese de convertirlas en espacios antes de comprometerse cuando trabaje con SCM. PERO NUNCA (!) MEZCLAR FICHAS Y ESPACIOS !!! Puede Y VOLVERÁ a introducir errores horribles.

6. some_method o foo_function, a CONSTANT, MyClass.

También se puede discutir sobre la sangría en los casos en que una llamada al método o algo se extiende por varias líneas, y se puede discutir sobre qué estilo de continuación de línea que va a utilizar. O rodea todo con () o haz el \ al final de la línea. Hago lo último, y también coloco operadores y otras cosas al comienzo de la siguiente línea.

# always insert a newline after a wrapped one 
from bla import foo, test, goo, \ 
       another_thing 

def some_method_thats_too_long_for_80_columns(foo_argument, bar_argument, bla_argument, 
               baz_argument): 

    do_something(test, bla, baz) 

    value = 123 * foo + ten \ 
      - bla 

    if test > 20 \ 
     and x < 4: 

     test_something() 

    elif foo > 7 \ 
     and bla == 2 \ 
     or me == blaaaaaa: 

     test_the_megamoth() 

También tengo algunas directrices para las operaciones de comparación, siempre uso is(not) para comprobar contra None True False y nunca hacer una comparación booleana implícita como if foo:, siempre lo hago if foo is True:, tipado dinámico es agradable, pero en algunos casos que acabo ¡quiero estar seguro de que la cosa hace lo correcto!

¡Otra cosa que hago es nunca usar cadenas vacías! Están en un archivo de constantes, en el resto del código tengo cosas como username == UNSET_USERNAME o label = UNSET_LABEL ¡es simplemente más descriptivo de esa manera!

También tengo algunas pautas estrictas de espacio en blanco y otras cosas loco, pero me gusta (porque estoy loco por ella), que incluso escribió un script que comprueba mi código:
http://github.com/BonsaiDen/Atarashii/blob/master/checkstyle

ADVERTENCIA (!): ¡Herirá tus sentimientos! Incluso más que JSLint ...

Pero eso son solo mis 2 centavos.