El Blog Invent with Python

El Zen de Python de Tim Peters son 20 pautas para el diseño del lenguaje Python. Su código Python no necesariamente tiene que seguir estas pautas, pero es bueno tenerlas en cuenta. El Zen de Python es un huevo de Pascua, o broma oculta, que aparece si corres import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful 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!

NOTA: Misteriosamente, solo 19 de las pautas están escritas. Según los informes, Guido van Rosum dijo que el aforismo número 20 desaparecido es » una extraña broma de Tim Peters.»

Al final, estas directrices son opiniones que se pueden argumentar a favor o en contra. Al igual que todos los buenos conjuntos de códigos morales, a veces se contradicen a sí mismos para proporcionar la mayor flexibilidad. Aquí está mi propia interpretación de estos aforismos:

Lo bello es mejor que lo feo.

Los programadores a menudo escriben código rápidamente sin preocuparse por la legibilidad. Si bien el código no tiene que ser legible, el código del lenguaje Python en sí debe ser pensado, consistente y agradable de usar. Por supuesto, no todos los scripts necesitan ser hermosos, y la belleza es subjetiva, pero gran parte de la popularidad de Python es el resultado de ser tan fácil de trabajar.

Lo explícito es mejor que lo implícito.

«Este aforismo se explica por sí mismo», eso sería una explicación terrible para cualquier aforismo. Del mismo modo, es mejor que el código sea detallado y explícito. Debe evitar ocultar la funcionalidad del código detrás de características de lenguaje oscuro que requieren familiaridad para comprender completamente.

Lo simple es mejor que lo complejo. Complejo es mejor que complicado.

Estos dos aforismos nos recuerdan que construir cualquier cosa se puede hacer utilizando técnicas simples o complejas. Con un problema simple, como construir una pajarera, una solución simple es mejor. La construcción de un motor de tren diésel, por otro lado, es un problema complejo que requiere técnicas complejas. Incluso si técnicamente pudiera hacer un motor de tren diesel utilizando técnicas de caseta de pájaros, probablemente terminaría con una disposición complicada de Rube Goldberg de piezas de caseta de pájaros que no sería una solución ideal. Prefiera la simplicidad a la complejidad, pero conozca los límites de la simplicidad.

Plano es mejor que anidado.

A los programadores les encanta organizar las cosas en categorías, especialmente categorías que contienen subcategorías que contienen otras subcategorías. Estas jerarquías a menudo no agregan organización tanto como agregan burocracia. Está bien tener código en un solo módulo o clase de capa superior en lugar de dividirlo en múltiples submódulos o subclases. Si crea paquetes y módulos que requieren código como import spam.eggs.bacon.ham.foo.bar, entonces está haciendo que su código sea demasiado complicado.

Disperso es mejor que denso.

A los programadores a menudo les gusta meter tanta funcionalidad en el menor código posible, como los de una sola línea como los siguientes: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

La legibilidad cuenta.

Mientras que strcmp() puede significar obviamente la función de «comparación de cadenas» con alguien que ha estado programando en C desde la década de 1970, las computadoras modernas tienen suficiente memoria para escribir el nombre completo de la función. No deje caer vocales de sus nombres ni escriba un código demasiado conciso. El código se lee más a menudo de lo que se escribe, por lo que el código explícito y legible es más importante que el código conciso e indocumentado.

Los casos especiales no son lo suficientemente especiales como para romper las reglas. Aunque la practicidad vence a la pureza.

Estos dos aforismos, que vienen como un conjunto, se contradicen entre sí. La programación está llena de» mejores prácticas » por las que los programadores deben esforzarse en su código. Esquivar estas prácticas para un hackeo rápido puede ser tentador, pero puede llevar a un nido de ratas de código inconsistente e ilegible. Sin embargo, hacer lo imposible para adherirse a las reglas puede resultar en un código altamente abstracto e ilegible. El intento del lenguaje de programación Java de ajustar todo el código a su paradigma orientado a objetos a menudo resulta en una gran cantidad de código repetitivo incluso para el programa más pequeño. Caminar la línea entre estos dos aforismos se vuelve más fácil con la experiencia. Y con el tiempo, no solo aprenderás las reglas, sino también cuándo romperlas.

Los errores nunca deben pasar en silencio. A menos que se silencie explícitamente.

El hecho de que los programadores a menudo ignoren los mensajes de error no significa que el programa deba dejar de emitirlos. Los errores silenciosos pueden ocurrir cuando las funciones devuelven códigos de error o None en lugar de generar excepciones. Estos dos aforismos nos dicen que es mejor que un programa fail fast y se bloquee que silenciar el error y continuar ejecutando el programa. Los errores que inevitablemente ocurren más adelante serán más difíciles de depurar, ya que están muy alejados de la causa original. Aunque siempre puede elegir ignorar explícitamente los errores que causan sus programas, solo asegúrese de tomar la decisión consciente de hacerlo.

Ante la ambigüedad, rechaza la tentación de adivinar.

Las computadoras han hecho supersticiosos a los humanos: Para exorcizar a los demonios en nuestras computadoras, realizamos el ritual sagrado de apagarlos y encenderlos. Supuestamente esto solucionará cualquier problema misterioso. Sin embargo, las computadoras no son mágicas. Si su código no funciona, hay una razón y solo el pensamiento crítico y cuidadoso lo resolverá. Rechaza la tentación de intentar soluciones ciegamente hasta que algo parezca funcionar; a menudo simplemente has enmascarado el problema en lugar de solucionarlo.

Debe haber una—y preferiblemente solo una-forma obvia de hacerlo.

Este es un lateral en contra del lema del lenguaje de programación Perl, » ¡Hay más de una manera de hacerlo!»Resulta que tener tres o cuatro formas diferentes de escribir código que hacen lo mismo es un arma de doble filo: tienes flexibilidad en la forma de escribir código, pero ahora tienes que aprender todas las formas posibles en que se podría haber escrito para leerlo. Esta flexibilidad no vale la pena el esfuerzo 3x o 4x necesario para aprender un lenguaje de programación.

Aunque esa forma puede no ser obvia al principio a menos que seas holandés.

Esta línea es una broma. Guido van Rossum, el creador y BDFL (Dictador Benévolo de por Vida) de Python, es holandés. Sin embargo, ni siquiera este aforismo impidió que Python incorporara tres formas diferentes de formatear cadenas.

Ahora es mejor que nunca. Aunque nunca es a menudo mejor que *ahora mismo*.

Estos dos aforismos nos dicen que el código que se cuelga o queda atrapado en bucles infinitos es obviamente peor que el código que no lo hace.

Si la implementación es difícil de explicar, es una mala idea. Si la implementación es fácil de explicar, puede ser una buena idea.

Python se esfuerza por hacer el trabajo del programador más fácil en lugar de acomodar la computadora para que un programa se ejecute más rápido. Y los programas deben ser comprensibles no solo para el programador que los escribió, sino también para otros programadores que mantienen el código. Estos dos aforismos nos recuerdan que si el código de «alto rendimiento» es tan complicado que es imposible de entender y depurar para los programadores, entonces es código malo. Pero, por desgracia, el hecho de que sea fácil explicar el código de un programa a otra persona no significa que no sea un código malo. La programación es difícil.

Los espacios de nombres son una gran idea, ¡hagamos más de esos!

Los espacios de nombres (y también los ámbitos local y global) son clave para evitar que los nombres de un módulo o ámbito entren en conflicto con los nombres de otro. Pero también recuerde que plano es mejor que anidado: A pesar de lo grandes que son, los espacios de nombres deben hacerse solo para evitar conflictos de nombres y no para agregar una categorización innecesaria.

Al igual que todas las opiniones sobre programación, las que he escrito aquí se pueden argumentar en contra o simplemente pueden ser irrelevantes para su situación. Discutir sobre cómo debe escribirse el código rara vez es tan productivo como crees que es. (A menos que estés escribiendo un libro completo lleno de opiniones de programación.)