Tim Peters, activo colaborador de Python, escribió hace años, unos principios que bien podrían ser la filosofía o Zen de Python. Estos principios se incorporaron dentro del propio Python y se pueden ver escribiendo import this en el prompt interactivo de Python.
>>> import this
The Zen of Python, by Tim Peters
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!
Estos principios que se pueden aplicar a la programación en Python son:
Bello es mejor que feo
Un código bien escrito, legible, coherente, siempre es mejor que uno mal escrito, ilegible e incoherente, por tanto, los programadores Python desarrollan un código bien diseñado, eficiente y elegante. En la PSF se pueden encontrar la PEP 8, guía de estilos para programar en Python https://www.python.org/dev/peps/pep-0008/ con recomendaciones para la indentación, el uso de tabulaciones, espacios, etc.
Explícito es mejor que implícito
Si se puede escribir el código entendible, haciendo explícito lo que se quiere programar, siempre es mejor que escribir código y luego al revisarlo tener que imaginarse que significa cada pieza de código. De estas dos sentencias, ¿cuál resulta mas comprensible?
vcs = [‘a’,’e’,’i’,’o’,’u’]
vocales = [‘a’,’e’,’i’,’o’,’u’]
Simple es mejor que complejo
Cuanto más simple sea el código más fácil será trabajar con el o realizar futuras modificaciones. Además del código se tiene en cuenta el resultado, cuanto más simple sea una interfaz más fácil lo tendrá el usuario final para trabajar con ella. Comprueba esté código y mira cuál te resulta más simple.
Ejemplo 1
a = [1,2,3,4,5,6,7,8,9]
for x in range(len(a)):
print(a[x])
Ejemplo 2
numeros = [1,2,3,4,5,6,7,8,9]
for numero in numeros:
print(numero)
Complejo es mejor que complicado
Si hay varias formas de solucionar algo, se espera usas la que resulte mas simple.
Plano es mejor que anidado.
A veces es necesario usar el anidamiento o estructuras complejas, Python promueve que se haga lo mas plano posible en aras de la comprensión para futuras modificaciones u optimizaciones del código.
Disperso es mejor que denso
Es mejor dejar los espacios oportunos y no querer que todo el código entre en una linea. El primer código es mas disperso que el segundo
>>> numeros = [ 1 , 2 , 3 ]; print( numeros )
[1, 2, 3]
>>> numeros=[1,2,3];print(numeros)
[1, 2, 3]
La legibilidad cuenta
Por lo que, aunque el código sea complejo se intenta que sea legible y fácil de entender, escribiendo comentarios aclaratorios.
Los casos especiales no son suficientemente especiales para romper las reglas
Siempre se debería hacer que el código siga las normas y usar las soluciones generales para solventar los problemas.
Aunque lo práctico supera a la pureza
Siempre puede existir alguna excepción a la regla.
Los errores nunca deberían pasar silenciosamente
Se deberían tratar los errores con Try except para mostrar un mensaje en el caso de que se produzcan, haciendo que la persona que usa el software sepa lo que está ocurriendo.
A menos que sean explícitamente silenciados
Es decir, que el error no sea relevante y simplemente se quiera continuar con la ejecución del código.
Ante la ambigüedad, rechaza la tentación de adivinar
Lo que vuelve a indicar que es mejor que el código sea claro, es decir, es mejor que se escriba a+(b*c) a que se escriba a+b*c. Aunque el resultado sea el mismo, resulta más clara la primera opción.
Debería haber una, y preferiblemente solo una, manera obvia de hacerlo
Teniendo como premisa que simple es mejor que complejo, aunque varios programadores busquen la solución a un mismo problema de forma diferente siempre existirá la forma mas simple y obvia.
Aunque esa manera pueda no ser obvia al principio a menos que seas holandés
Es una referencia al programador, quien mejor que el debería saber cuál es la forma mas obvia de hacer las cosas con Python.
Ahora es mejor que nunca
A veces es mejor no dedicar tanto tiempo a planificar, simplemente se puede realizar algo que funcione y optimizarlo más tarde.
Aunque nunca es a veces mejor que ahora mismo
Siempre es bueno tener en cuenta la posibilidad de la mejora del código antes de comenzar ya que se puede acabar en un callejón sin salida.
Si la implementación es difícil de explicar, es una mala idea
Si la implementación es complicada quizás no sea buena idea publicarlo así.
Si la implementación es fácil de explicar, puede ser una buena idea
Aunque la implementación sea fácil hay que usar el sentido común para saber si la idea es buena.
Los namespaces son una idea genial, ¡Tengamos más!
Los namespaces son un sistema para asegurar que todos los nombres en un script Python sean únicos y puedan ser usados sin conflicto.