Con innumerables mejores prácticas de Python circulando en línea, las opiniones sobre cada una pueden variar dependiendo de a quién le preguntes. Internet ha democratizado la experiencia, permitiendo que cualquiera –incluyéndome a mí– comparta sus puntos de vista. Sin embargo, en este artículo, nos centraremos en 10 mejores prácticas eternas de Python que han logrado un consenso generalizado y se consideran fundamentales.

Hoja de referencia de pandas

Hoja de referencia de comandos de Git

Las 50 preguntas principales de la entrevista SQL

Consejo 1: Las funciones deben especificar el parámetro y el tipo de retorno
Al definir una función, siempre desea especificar cuáles son los tipos de argumentos y también qué tipo de datos devuelve el resultado de la función. Esto le ayudaría a usted y a los desarrolladores de su equipo a saber qué esperar sin tener que utilizar siempre declaraciones impresas para obtener una comprensión visual.

Consejo 2: Las funciones deben estar en el mismo nivel de abstracción
Cuando hablamos de funciones que están en el mismo nivel de abstracción, nos referimos a la idea de que una función debe realizar una tarea única y bien definida. Esa tarea debe tener un nivel constante de abstracción en toda la función. En otras palabras, la función debe centrarse en un nivel específico de detalle o complejidad, y todas las operaciones de las funciones deben operar en ese mismo nivel.

Consejo 3: Las funciones deben ser pequeñas
Una función debe ser reutilizable. Y cuanto mayor sea la función, menos probabilidades habrá de que sea reutilizable. Esto también se correlaciona con por qué una función debería hacer solo una cosa. Si solo hace una cosa, es muy probable que sea pequeño.

Consejo 4: Principios abiertos y cerrados
El principio abierto-cerrado (OCP) establece que una clase, método o función debe estar abierta para extensión pero no para modificación. Esto significa que cualquier clase, método o función definida se puede reutilizar o ampliar fácilmente para múltiples instancias sin cambiar su código.
Esto no cumple con OCP porque cada vez que hay un nuevo país, necesitaríamos escribir una nueva declaración if para complementarlo. Esto puede parecer sencillo ahora, pero imaginemos que tenemos 100 o más países a tener en cuenta. ¿Cómo se vería eso?

Consejo 5: Evite los comentarios a toda costa
Los comentarios tienen una manera de ser falsamente ciertos. Desvían la mente del lector de lo que realmente hace el código a lo que otra persona dice que está haciendo.

Esto puede volverse muy problemático a medida que pasa el tiempo y el código recibe actualizaciones o cambios. En algún momento, el comentario se convierte en una mentira y ahora todos tienen que observar la verdad a través del lente de la mentira.

Los comentarios deben evitarse a toda costa. Un comentario obliga al lector a heredar su pensamiento, que en el mejor de los casos pertenece al pasado. Cuando una función o clase cambia, lo más probable es que sus comentarios no cambien con ella. Lo más probable es que impidan al lector pensar en el futuro.

Un comentario significa que el escritor era mentalmente incapaz de proporcionar un nombre de clase, función o variable bien descriptivo. Expone la actitud mediocre del programador y obliga al equipo a heredar esa actitud.

Consejo 6: Evite los números mágicos
Un Número Mágico es un valor codificado que puede cambiar en una etapa posterior, pero que, por lo tanto, puede ser difícil de actualizar.

Por ejemplo, digamos que tienes una página que muestra los últimos 50 pedidos en una página de descripción general de "Tus pedidos". 50 es el número mágico aquí porque no está establecido mediante un estándar o convención, es un número que usted inventó por los motivos descritos en la especificación.

Ahora, lo que debe hacer es tener los 50 en diferentes lugares: su secuencia de comandos SQL (SELECCIONE LOS 50 PRINCIPALES * DE los pedidos), su sitio web (Sus últimos 50 pedidos), el inicio de sesión de su pedido (para (i = 0; i

Consejo 7: Evite el anidamiento profundo
Limite los niveles de anidamiento dentro de bucles, condicionales o funciones para mejorar la legibilidad.

Consejo 8: Evite las rutas de codificación
Abstenerse de codificar rutas de archivos o URL; utilice archivos de configuración o variables de entorno en su lugar.

Consejo 9: Las clases deben ser pequeñas
¡Sí! Las clases deben ser lo más pequeñas posible. Como funciones.

La única diferencia es que en las funciones, el tamaño está determinado por el número de líneas en esa función, mientras que en las clases, está determinado por el número de responsabilidades en esa clase.

Por lo general, el nombre de una clase representa el tipo de responsabilidades que podría poseer, pero cuando el nombre es ambiguo o demasiado general, lo más probable es que le estemos dando demasiada responsabilidad.

Esto nos lleva de regreso al SRP (principio de responsabilidad única), que establece que una clase solo debe tener una razón, una responsabilidad, para cambiar.

Consejo 10: Evite expresiones ternarias complejas
Abstenerse de utilizar expresiones ternarias demasiado complejas; favorezca la legibilidad sobre la brevedad para que el código sea más comprensible.