El Zen de
Python se compone de 19 principios para escribir código Pythónico (claro,
preciso y sencillo), que se encuentran contenidos en la definición de PEP 20. Su objetivo es homogeneizar las formas de escritura de código, tomando las mejores
prácticas, y es algo que tanto tú (como lector de código) como tus colegas
(como lectores de tu código) agradecerán conocer e implementar, ya que los ayudará a escribir un código de mayor calidad.
Aquí los adaptamos
e interpretamos, para que puedas implementarlos desde ya en tus proyectos en
Python:
- Bello es mejor que feo: Python se caracteriza primero que nada por su superioridad estética,
ante los demás lenguajes de programación. ¡Aprovéchala para que tu código luzca
de esa manera!
- Explícito es mejor que implícito: Debes lograr que quien lea tu código no
necesite hacer interpretaciones o saber de antemano estructuras propias que has
creado. Prioriza hacer más fácil que las otras personas entiendan el código,
incluso si debes desarrollarlo en unas líneas de código más.
- Simple es mejor que complejo: No hay mérito en plantear una solución extremadamente
sofisticada a un problema que puede resolverse de manera simple y directa. Es
mejor tener una implementación simple, que ocupe pocas líneas de código y sea
entendible, a que sea una larga y complicada.
- Complejo es mejor que complicado: Si por optimizar únicamente la brevedad y simplicidad,
acabamos con un código complicado de entender, demos un paso atrás: es mejor un
código más comprensible, aún si complejo, que un código complicado de entender.
En resumen: Simple > Complejo > Complicado.
- Plano es mejor que anidado: Es común dejarse llevar por la tentación (en Python y otros lenguajes
de programación), de pretender que una función o un objeto resuelva todos los
problemas. Cuando te has dado cuenta, anidaste condicionales dentro de bucles
dentro de funciones dentro de otros condicionales, dentro de otro bucle. En
Python es sencillo detectarlo porque lo evidencian la cantidad de indentaciones
necesarias. Son preferibles las estructuras simples y planas. Sino únicamente lograrás
agotar al lector de tu código.
- Disperso es mejor que denso: Python implementa este principio de manera obligatoria a través de la
indentación, haciendo inevitable que el código sea menos compacto y muestre sus
jerarquías propias. Sin embargo, ciertas estructuras como comprensión de
listas, pueden volverse densas rápidamente.
- La legibilidad es importante: En la industria es muy común trabajar en
equipos, por proyectos, y manteniendo código ya escrito. Es importante que
otros programadores puedan entender lo que has escrito en tu programa.
Nuevamente: hay más mérito en plantear soluciones simples a los problemas, que
soluciones extremadamente complicadas cuando no son requeridas.
- Los casos especiales no son lo suficientemente especiales como para
romper las reglas (sin embargo, la practicidad le gana a la pureza): si te encuentras invirtiendo
muchísimo tiempo en intentar cuadrar tu código a las reglas anteriores, puede
que valga una excepción para ser más eficientes y pragmáticos. ¡Pero que no se
convierta en un hábito! La razón de existir de las reglas, es que podamos
cumplirlas.
- Los errores nunca deberían pasar silenciosamente (a menos que se
silencien explícitamente): ocultar los errores solo traerá más y más errores (y más graves). Un
buen programador los gestiona y les presta atención a cada uno de ellos. Exista
la posibilidad de silenciar los errores, pero debes hacerlo con sumo criterio
cuando hayas descartado que puedan tener impacto en el sistema.
- Frente a la ambigüedad, evitar la tentación de adivinar: Nuestro código debería solamente
tener una interpretación. Mantente alerta a los casos en que en un contexto, el
código significa algo, y en otro, otra cosa. Puede que sea conveniente buscar
otra solución.
- Debería haber una, y preferiblemente solo una, manera obvia de hacer las cosas.
(A pesar de que esa manera no sea obvia a menos que seas holandés): Al adquirir experiencia en la
solución de los problemas de programación, estas maneras se irán manifestando.
Hasta entonces, practica. El "holandés" es Guido Van Rossum, creador de Python
(definitivamente, muy inteligente).
- Ahora es mejor que nunca: no dejes para mañana lo que puedes hacer hoy. Prioriza correctamente
para que flujo de trabajo no se vea interrumpido.
- …Aunque nunca es muchas veces mejor que ahora mismo: si
por hacer todo en el momento, poblamos el código de bugs, hubiera sido preferible
en ese caso no hacerlo nunca.
- Si la implementación es difícil de explicar, es una mala idea, pero si
es fácil de explicar, puede ser una buena idea: Un algoritmo es una secuencia de pasos para resolver
un problema. Si esta secuencia es lógica, racional, y fácil de explicar, ya has
dado el primer paso en la dirección correcta. Si es muy compleja explicarla,
puede que no convenga implementarla, ya que ni la habremos entendido nosotros.
Intenta explicársela a un pato de goma para el baño, y comprueba si te has
enredado.
