PDF de programación - Guía de estilo del código Python

Guía de estilo del código Python

http://mundogeek.net/traducciones/guia-estilo-py...

Bitácora
Traducciones
Tutorial de Python

Guía de estilo del código Python

Por Guido van Rossum, Barry Warsaw

Traducción al castellano por Raúl González Duque
el día 10 de Agosto de 2007
Introducción
En este documento se listan distintas convenciones utilizadas en el código
Python comprendido en la librería estándar de la distribución principal de
Python. Por favor refierase al PEP que describe las guías de estilo del código C
para la implementación en C de Python[1].

Este documento es una adaptación del ensayo original de Guido Guía de Estilo
de Python[2], con algunos añadidos de la guía de estilo de Barry[5]. En los
puntos en los que exista conflicto, se aplican las reglas de estilo de Guido para
los propósitos de este PEP. Este PEP puede estar aún incompleto (de hecho, es
posible que nunca llegue a completarse ).
La Consistencia Estúpida es el Demonio de las
Mentes Pequeñas
Una de las ideas clave de Guido es que el código se suele leer mucho más de lo
que se escribe. Las guías de estilo que proporciona este documento están
dirigidas a mejorar la legibilidad del código y hacerlo consistente a lo largo del
amplio espectro del código Python. Como dice el PEP 20[6], "La legibilidad
cuenta".

Una guía de estilo nos ayuda a lograr consistencia. Ser consistente con esta guía
de estilo es importante. La consistencia dentro de un proyecto es aún más
importante. La consistencia dentro de un módulo o función es la más
importante.

Pero lo más importante es saber cuándo ser inconsistente -- algunas veces la
guía de estilo simplemente no es aplicable. Cuando tengas dudas, usa tu juicio.
Mira ejemplos y decide qué te parece mejor. ¡Y no dudes en preguntar!

1 of 18

08/18/2017 01:18 PM

Guía de estilo del código Python

http://mundogeek.net/traducciones/guia-estilo-py...

Dos buenas razones para romper una regla en particular son:

1.

2.

Que al aplicar la regla el código se haga menos legible, incluso para
alguien que esté acostumbrado a leer código que sigue las normas.
Para ser consistente con código relacionado que también la rompe (quizás
por razones históricas) -- aunque esto también es una oportunidad de
arreglar el desaguisado de otra persona (al más puro estilo XP).

Formateo del código
Indentación

Usa 4 espacios por cada nivel de indentación.

Para código realmente antiguo que no quieras estropear, puedes continuar
usando tabuladores de 8 espacios.
¿Tabuladores o espacios?

Nunca mezcles tabuladores y espacios.

La forma más popular de indentar en Python es utilizar sólo espacios. La
segunda forma más popular es usar sólo tabuladores. El código indentado con
una mezcla de tabuladores y espacios debería reformatearse y usar espacios
exclusivamente. Cuando se invoca el intérprete de línea de comandos de Python
con la opción -t, este muestra avisos sobre código que mezcla tabuladores y
espacios. Cuando se utiliza -tt estos avisos se convierten en errores. ¡Estas
opciones son altamente recomendables!

Para nuevos proyectos, se recomienda firmemente el uso de espacios en lugar
de tabuladores. La mayoría de los editores tienen características que hacen esto
bastante sencillo.
Tamaño máximo de línea

Limita todas las líneas a un máximo de 79 caracteres.

Todavía existen muchos dispositivos por ahí que están limitados a 80 caracteres
por línea; además limitando el ancho de las ventanas a 80 caracteres posibilitas
el tener varias ventanas una al lado de otra. El ajuste de línea por defecto en
este tipo de dispositivos no da buenos resultados. Por lo tanto, por favor limita
todas las líneas a un máximo de 79 caracteres. Para cadenas de texto largas
(cadenas de documentación o comentarios), es aconsejable limitar el ancho a 72
caracteres.

2 of 18

08/18/2017 01:18 PM

Guía de estilo del código Python

http://mundogeek.net/traducciones/guia-estilo-py...

La forma preferida de dividir líneas largas es utilizar la característica de Python
de continuar las líneas de forma implícita dentro de paréntesis, corchetes y
llaves. Si es necesario, puedes añadir un par de paréntesis extra alrededor de
una expresión, pero algunas veces queda mejor usar una barra invertida.
Asegurate de indentar la línea siguiente de forma apropiada. Algunos ejemplos:

class Rectangle(Blob):

def __init__(self, width, height,
color='black', emphasis=None, highlight=0):
if width == 0 and height == 0 and \
color == 'red' and emphasis == 'strong' or \
highlight > 100:
raise ValueError("sorry, you lose")
if width == 0 and height == 0 and (color == 'red' or
emphasis is None):
raise ValueError("I don't think so")
Blob.__init__(self, width, height,
color, emphasis, highlight)

Líneas en blanco

Separa las funciones no anidadas y las definiciones de clases con dos líneas en
blanco.

Las definiciones de métodos dentro de una misma clase se separan con una
línea en blanco.

Se pueden usar líneas en blanco extra (de forma reservada) para separar grupos
de funciones relacionadas. Las líneas en blanco se pueden omitir entre un grupo
de funciones con una sola línea (por ejemplo, con un conjunto de funciones sin
implementación).

Usa líneas en blanco en las funciones, de forma limitada, para indicar secciones
lógicas.

Python acepta el caracter control-L (o lo que es lo mismo ^L) como un espacio
en blanco; muchas herramientas utilizan este caracter como separador de
páginas, por lo que puedes usarlos para separar páginas de secciones
relacionadas en tu archivo.
Codificación de caracteres (PEP 263)

El código de la distribución base de Python siempre debería utilizar las
codificaciones ASCII o Latin-1 (también conocida como ISO-8859-1). Para
Python 3.0 y superiores, se recomienda UTF-8 en lugar de Latin-1, ver PEP
3120.

3 of 18

08/18/2017 01:18 PM

Guía de estilo del código Python

http://mundogeek.net/traducciones/guia-estilo-py...

Los archivos que usan ASCII (o UTF-8, para Python 3.0) no deberían tener una
línea de especificación del juego de caracteres. Sólo debería usarse Latin-1 (o
UTF-8) cuando se necesite mencionar a un autor cuyo nombre requiera de
caracteres Latin-1 en un comentario o cadena de documentación; si no es así, la
forma adecuada de incluir datos no ASCII en literales de cadena es mediante los
caracteres de escape \x, \u y \U.

Para Python 3.0 y superiores, se recomienda la siguiente política para la librería
estándar (ver PEP 3131): Todos los identificadores en la librería estándar Python
DEBEN usar sólo caracteres ASCII, y DEBERÍAN usar palabras en ingĺés
siempre que esto sea posible (en muchos casos se utilizan abreviaturas y
términos técnicos que no forman parte del inglés). Además, los literales de
cadena y los comentarios también deben estar en ASCII. Las únicas excepciones
son (a) baterías de pruebas que comprueben las características no ASCII, y (b)
nombres de autores. Los autores cuyos nombres no estén basados en el alfabeto
latino DEBEN proporcionar una transcripción de sus nombres a este alfabeto.

Se recomienda a los proyectos de código abierto con audiencia global que
adopten políticas similares.
Imports

Normalmente los imports deberían colocarse en distintas líneas, por
ejemplo:

Sí:

import os
import sys

No:

import sys, os

aunque también es correcto hacer esto:

from subprocess import Popen, PIPE

Los imports se colocan siempre en la parte superior del archivo, justo
después de cualquier comentario o cadena de documentación del módulo, y
antes de las variables globales y las constantes del módulo.

Los imports deberían agruparse siguiendo el siguiente orden:

1.
2.

imports de la librería estándar
imports de proyectos de terceras partes relacionados

4 of 18

08/18/2017 01:18 PM

Guía de estilo del código Python

http://mundogeek.net/traducciones/guia-estilo-py...

3.

imports de aplicaciones locales/imports específicos de la librería

Deberías añadir una línea en blanco después de cada grupo de imports.

Si es necesario especificar los nombres públicos definidos por el módulo
con __all__ esto debería hacerse después de los imports.

Es muy desaconsejable el uso de imports relativos para importar código de
un paquete. Utiliza siempre la ruta absoluta del paquete para todos los
imports. Incluso ahora que el PEP 328 [7] está totalmente implementado en
Python 2.5, el usar imports relativos se desaconseja seriamente; los imports
absolutos son más portables y normalmente más legibles.

Cuando importes una clase de un módulo, normalmente es correcto hacer
esto

from myclass import MyClass
from foo.bar.yourclass import YourClass

Si esto causa colisiones de nombres con objetos locales, utiliza en su lugar

import myclass
import foo.bar.yourclass

y usa "myclass.MyClass" y "foo.bar.yourclass.YourClass" en el código

Espacios en blanco en expresiones y sentencias
Evita espacios en blanco extra en las siguientes situaciones:

Inmediatamente después de entrar en un paréntesis o antes de salir de un
paréntesis, corchete o llave.

Sí:
spam(ham[1], {eggs: 2})
No:
spam( ham[ 1 ], { eggs: 2 } )

Inmediatamente antes de una coma, punto y coma, o dos puntos:

Sí:
if x == 4: print x, y; x, y = y, x
No:
if x == 4 : print x , y ; x , y = y , x

5 of 18

08/18/2017 01:18 PM

Guía de estilo del código Python

http://mundogeek.net/traducciones/guia-estilo-py...

Inmediatamente antes de abrir un paréntesis para una lista de argumentos
de una llamada a una función:

Sí:
spam(1)
No:
spam (1)

Inmediatamente antes de abrir un paréntesis usado como índice o para
particionar (slicing):

Sí:
dict['key'] = list[index]
No:
dict ['key'] = list [index]

Más de un espacio alrededor de un operador de asignación (u otro
operador) para alinearlo con otro.

Sí:
x = 1
y = 2
long_variable = 3
No:
x = 1
y = 2
long_va