El Zen de Python

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.