Buenas Practicas Python
Consta de 19 reglas que de aplicarse correctamente en cualquier código para convertirlo en código Pythónico. Se pueden obtener ver en la definición de la PEP 20 https://www.python.org/dev/peps/pep-0020/ o ejecutando el siguiente código en cualquier intérprete:
Bonito es mejor que feo
Beautiful is better than ugly
Los adjetivos de bonito o feo suelen ser muy subjetivos aunque cuando se refiere a código, cualquiera con algunas decenas de miles de líneas escritas puede apreciar si un código es bonito o feo, aplicando las siguientes reglas o con reglas propias que da la experiencia.
Explícito es mejor que implícito
Explicit is better than implicit
Cuando un código es explícito, no requiere que el lector tenga que intuir o saber de antemano algún elemento implícito del sistema, haciendo que la legibilidad mejore considerablemente.
A veces convertir un código implícito en explícito es tan simple como añadir algunas variables intermedias con nombres apropiados, o no concatenar funciones o simplemente no hacer uso de variables globales sino pasar las variables usando argumentos.
Simple es mejor que complejo
Simple is better than complex.
Un sistema complejo se define como un sistema compuesto de muchas partes independientes conectadas entre sí, pero que no tienen relaciones ocultas entre los componentes.
Si el sistema está correctamente implementado, cada parte independiente será simple si se estudia de forma aislada, por lo que, el estudio del sistema completo se podría simplificar en el estudio de cada parte simple.
Complejo es mejor que complicado
Complex is better than complicated.
Sin embargo, un sistema complicado, se compone de elementos simples que no son independientes entre sí, sino que el sistema conoce de alguna lógica extra que convierte el sistema en complicado.
Por tanto por orden de preferencia sería (> == mejor que):
Simple > Complejo > Complicado
Plano es mejor que anidado
Flat is better than nested.
La capacidad de retención y comprensión de cada desarrollador es limitada, por tanto si se anidan las sentencias en vez de mantenerlas lo más planas posibles, se suele mermar la capacidad cansando al lector del código.
Una forma de aplanar un código anidado es usando funciones planas y otra podría ser usando listas por comprensión, aunque la segunda opción suele quedar muy densa fácilmente.
Disperso es mejor que denso
Sparse is better than dense
Cuando se aumenta la densidad del código haciendo en pocas líneas muchas operaciones se puede hacer perder el foco del lector, por tanto es muy recomendable añadir espacios entre bloques lógicos.
La legibilidad importa
Readability counts.
El código se escribe una vez pero se leen cientos de veces, por lo tanto es muy importante prestar especial atención a mejorar la legibilidad lo más posible, eligiendo los mejores nombres, separando funciones convenientemente o clases cuando son necesarios.
Existen muchas técnicas para mejorarlo e incluso libros sobre este tema como los principios SOLID o los libros de Clean Code que son totalmente recomendables.
Los casos especiales no son lo suficientemente especiales para romper reglas
Special cases aren’t special enough to break the rules
Cuando se definen unas reglas hay que cumplirlas, de lo contrario no tienen razón de existir. Los casos «especiales» son la excusa que se pone para romper las reglas pero realmente son sinónimo de «conozco las reglas pero en vez de cambiar el código para cumplirarlas, prefiero romperlas», lo que debería de ser inadmisible dado que a la larga (conlleva al desastre).
Practicidad vence a la pureza
Although practicality beats purity
En multitud de ocasiones nos encontramos en la situación de querer escribir el código más puro, que sigue todos los patrones de diseño «a raja tabla» y que conlleva a que los sistemas sean demasiado genéricos o que se tarden una eternidad en desarrollar, es muy importante encontrar un equilibrio entre lo que es práctico (e importante) y la pureza.
Los errores nunca deberían de ocurrir silenciosamente
Errors should never pass silently.
Cuando se trabaja bajo presión y se encuentran errores se tienden a ocultar o a tomar medidas demasiado drásticas como la siguiente:
O lo que es lo mismo «se que este código falla de vez en cuando, cuando lo haga sigue sin más», esto no es solo un antipatrón sino que demuestra apatía y una desgana de hacer código profesionalmente. Si hay un error debe ser visible para poder ser arreglado.
A no ser que se silencien explícitamente
Unless explicitly silenced
Existen excepciones al caso anterior que se dan cuando se ha estudiado la situación, se conoce el error y explícitamente se silencia (o se actúa en consecuencia).
Si el error que se ha detectado es un ValueError (por ejemplo) pero se sabe que no es problemático, se debe de manejar adecuadamente, incluso pudiendo ser silenciado.
try:
codigo_erroneo()
except ValueError:
logger.debug('Value Error manejado correctamente')
En el caso de ambigüedad, rechaza la tentación de adivinar
In the face of ambiguity, refuse the temptation to guess
Este concepto aplica a muchos ámbitos del desarrollo, es mucho mejor tener claro qué se está construyendo y poder crear tests, que exactamente definan y comprueben el buen comportamiento del sistema, eliminando cualquier ambigüedad.
Debería de haber una – y preferiblemente sólo una – forma obvia de hacerlo
There should be one– and preferably only one –obvious way to do it
Si la forma de implementar el problema no parece obvia, quizás no sea la más correcta y haya que seguir pensando en otra opción.
Aunque la forma no parezca obvia a la primera, a no ser que seas Holandés
Although that way may not be obvious at first unless you’re Dutch
Es normal que no aparezca la forma obvia la primera vez que piensa la solución, por lo que puede requerir de un método iterativo.
El guiño que se añade en esta regla sobre los holandeses hace referencia la nacionalidad del Dictador Benevolente y creador de Python Guido van Rossum.
Ahora es mejor que nunca
Now is better than never
En el desarrollo de software siempre hay tareas que realizar y si no se priorizan las tareas importantes para hacerlas cuando salen los problemas, estos pueden alargarse en el tiempo hasta no hacerlas nunca.
Although never is often better than right now
Quiere decir que no hay que forzar la realización de tareas tanto como para dejar lo que se está desarrollando actualmente, para desarrollar una tarea nueva, evitando así el cambio de contexto.
Si la implementación es difícil de explicar, es una mala idea
If the implementation is hard to explain, it’s a bad idea
Esta regla suele aplicarse en muchos ámbitos en general, dado que si no eres capaz de explicar la idea de forma simple es que no la visualizas de forma simple por lo que quizás sea necesario consensuar la solución hasta tenerla clara.
Si la implementación es fácil de explicar, es una buena idea
If the implementation is easy to explain, it may be a good idea
Cuando se puede explicar la idea a cualquier otra persona (o patito de goma) suele ser síntoma de tener los conceptos claros y de ser una solución genial.
Los espacios de nombres son una buena idea, ¡usemos más de ellos!
Namespaces are one honking great idea — let’s do more of those!
Los espacios de nombres en Python se pueden crear de múltiples formas y ayudan mucho a desacoplar código y de hacerlo más modular, por lo que se recomienda usarlos más.
Importancia
La importancia de la PEP 20 radica en intentar definir una guía de principios de cómo debe de crearse el código para considerarse Pythónico.
El Zen de Python podría exportarse a otros lenguajes dado que muchas de sus reglas no son únicas para Python sino aplicables a cualquier lenguaje.
Dado que Python es uno de los pocos lenguajes con unas directrices tan claras hace que el lenguaje sea aún más extraordinario.
Este articulo y copy fue recopilado y usado de: elpythonista . com , todos los derechos y propiedad es de quien lo escribio este resumen solo es para efectos didacticos y de uso para estudiantes.
Comentarios