De todos los PEP (Python Enhancement Proposals) uno de los más populares es el PEP8, que nos proporciona un marco de referencia sobre buenas prácticas y estilo de programación en Python, por ejemplo:
- Convención de nombres para variables, constantes, funciones, clases, excepciones…
- Cómo y cuándo realizar comentarios multilínea o de una sólo línea.
- Reglas de identación: uso de espacios y tabulaciones.
- Uso de anotaciones en funciones.
Si repasamos el documento original de PEP8 vemos que no es excesivamente técnico. El objetivo de todas sus recomendaciones es crear un código más legible y que pueda ser (re)utilizado por otros programadores sin demasiado dolor de cabeza. Algunas de las recomendaciones a base de práctica las vamos aprendiendo y aplicando de forma casi automática, pero es difícil estar pendiente de cada una de las convenciones. No es práctico tampoco tener el PEP8 al lado contínuamente cuando escribimos código.
Para facilitar un poco nuestra vida, existen herramientas y plugins para la mayoría de IDEs modernos que automatizan la revisión de nuestro código -a medida que lo vamos escribiendo- según las reglas de PEP8.
- PEP8 para ATOM.
Ejemplo: plugin pep8 para Atom
- PEP8 Autoformat para Sublime Text.
- AutoPEP8 para Spyder.
- Flake8 para VIM (en este artículo puedes ver cómo instalar plugins para VIM con Pathogen)
Algunos IDEs como PyCharm desde la versión 2.7 lo incorporan de serie, de manera que podemos activar la revisión de código como una opción más.
Existe además herramientas online como pep8online que puede servir de ayuda. No soy muy amigo de este tipo de utilidades en las que tenemos que subir nuestro código, pero sirve para un apuro o simplemente para revisar rápidamente algunas porciones de código.
Por último, creo que para entender el PEP8 es necesario leer previamente The Zen of Python. Este documento -que por otro lado es el PEP20– escrito por Tim Peters incluye 19 aforismos que describen conceptualmente la forma ideal de escribir código en Python:
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!
Tenéis todos los PEPs disponibles en la web de Python.
Que os haya sido leve el lunes 🙂