Buenas Practicas De Programacion Pep 8

Un poco de historia

El estandar PEP 8 es un documento que provee guías y mejores práacticas sobre como esccribir código Python. Fue creado en 2001 por Guido van Rossum, Barry Warsaw y Nick Coghlan. El énfasis principal del documento es documentar prácticas para mejorar la legibilidad y consistencia del código Python.

Contenidos

El documento da convenciones utilizadas para escribir código python de calidad, define una cadena de prioridades para generar el código (primero va el estándar del proyecto, luego el estándar del lenguaje), posteriormente vienen las recomendaciones, las cuales son de tipo estilístico para mantener un estilo consistente y evitar problemas con versiones, con codificaciones de archivos, y en general como debe verse el código python.

Es importante hacer notar que un buen programa de linting o un formateador de código (como autopep8) puede arreglar de manera automática casi todos los puntos mencionados en el documento.

Los puntos mas importantes de la lista de recomendaciones

Indentación

La indentación estándar son 4 espacios, no se deben usar tabs. Esto permite una buena alineación cuando se anidan estructuras como los if’s o for, ya que el cuerpo del código queda claramente a nivel:

if a == 'a':
    print('foo')

o

for i in mylist:
    f(i)

Lo cual es legible, no ocupa demasiado espacio y como opinión personal, es estéticamente agradable a la vista.

Máxima longitud de líneas

El estándar recomienda una longitud máxima de 80 caracteres por línea, y a continuación define varias maneras de hacer saltos de línea para estructuras de datos largas.

lineas vacías

Las líneas vacías son ignoradas por el intérprete, pero se recomienda que existan entre funciones o métodos, que se utilicen 2 líneas de separación entre clases y que se dejen dos líneas entre el docstring y el comienzo del cuerpo del código.

Codificación de archivos

Idealmente los archivos deben estar codificados en ASCII para aplicaciones en Python 2 o en UTF-8 para python 3, esto para permitir la portabilidad del código entre sistemas y facilitar su distribución, sobre todo si hay posibilidad de que llegue a la biblioteca estándar. De todas maneras, los intérpretes de python, no reconocen otros tipos de archivos, así que este apartado es mas para los desarrolladores del intérprete, en mi opinión.

Imports

El estándar indica que los imports deben ir al principio del archivo (posteriormente se desarrolló una jerarquía de imports, que viene implementada en pylint). Pero el PEP 8, sólo indica que de preferencia los imports sean absolutos.

Docstrings

Los doctrings se colocan al inicio de los módulos, justo después de la definición de clases y funciones. Los docstrings deben ir entre comillas triples """

#!/usr/bin/env python3
import os

"""
Este módulo no hace nada
"""

class MyClass:
	"""
	Ejemplo de una clase vacía
	"""
	
	def __init__(self):
		"""
		constructor de la clase
		"""
		pass
	
	def my_metodo(self):
		"""
		Este es un metodo para la clase, no hace nada
		"""
		pass

Convenciones de nombres

La convención para nombres del estándar puede ser resumida de la siguiente manera:

Conclusión

Codificar utilizando un estándar es una buena práctica que permite a otros programadores comprender nuestro código, ya sea si compartimos un proyecto personal, open source o en la empresa. Es importante entender que el código es leído mas veces que escrito, ya sea como ejemplo, para adaptarlo , para reutilizarlo o para modificar funcionalidad. Por lo que es importante que sea legible. Podemos incluso definir una convención de nombres sobre el estándar de la industria que signifique algo dentro de nuestra organización, como la convención de anteponer el tipo de dato a las variables para saber de un vistazo que tipo de dato contienen.