Malos hábitos de los programadores que secretamente aman romper las reglas

Se sabe que, a veces, es placentero romper las reglas, ya sea por exceder el límite de velocidad en una milla o ignorar el tiempo vencido en un parquímetro. Para los programadores, las relaciones con las reglas son particularmente extrañas. Por un lado, el código es un conjunto de reglas que deben ejecutarse de manera perfecta. Pero también hay otro nivel de reglas, que no son tan sagradas y que los propios programadores suelen romper.

El debate sobre si las personas deben romper sus propias reglas lleva mucho tiempo. Algunas de estas reglas están desactualizadas, otras fueron mal concebidas desde el principio, y otras más se han convertido en costumbres. Hace algunos años se compiló una lista de malos hábitos de programación que los programadores secretamente adoran. Ahora se presentan 10 de esos hábitos.

10 malos hábitos de programación que los desarrolladores adoran

1. Código sin comentarios

   • A menudo, el código sin comentarios es difícil de entender y depurar. Los buenos comentarios se consideran una parte importante de la programación, pero en ocasiones los comentarios pueden empeorar las cosas. La documentación puede ser inconsistente o estar desactualizada, y a veces los comentarios se escriben en un idioma que no todos entienden. Por eso, algunos desarrolladores prefieren escribir funciones simples y usar nombres descriptivos para las variables en lugar de comentarios.
   • Problemas con los comentarios: A veces los comentarios no corresponden al código. El equipo de documentación puede estar en otro lugar o simplemente no tener tiempo para actualizarlos. En ocasiones, los programadores no actualizan los comentarios después de modificar el código.
   • Enfoque alternativo: En lugar de comentarios, se pueden escribir funciones simples y cortas con nombres descriptivos para las variables. Esto ayuda a entender el código sin explicaciones adicionales.

2. Código lento

   • Para que el código sea rápido, debe ser simple. Sin embargo, a veces lo simple y lento es mejor que lo complejo y rápido. En algunos casos, el código lento es más fácil de entender y mantener.
   • Equilibrio entre velocidad y complejidad: El código rápido a menudo es complejo, lo que dificulta su comprensión y mantenimiento. A veces es mejor optar por un código más lento pero comprensible, especialmente si la velocidad no es un factor crítico.

3. Código extendido

   • El uso de nuevos operadores y construcciones puede hacer que el código sea más corto, pero no necesariamente más fácil de entender. Algunos programadores prefieren escribir código más largo pero más legible.
   • Ejemplo: A algunos desarrolladores les gusta usar nuevos operadores en JavaScript para hacer el código más compacto. Sin embargo, esto puede dificultar su lectura y comprensión para otros.
   • Contexto histórico: Lenguajes como APL, que buscaban la máxima compacidad, prácticamente han desaparecido. Otros lenguajes, como Python, evitan construcciones complejas y permanecen populares gracias a su simplicidad y legibilidad.

4. Código antiguo

   • Algunos piensan que usar todas las posibilidades del lenguaje de programación es una buena práctica. Sin embargo, demasiadas funciones pueden causar confusión. Limitar la cantidad de funciones utilizadas puede reducir la confusión y hacer el código más fácil de leer.
   • Exceso de características: Demasiadas abstracciones y construcciones sintácticas pueden dificultar la comprensión del código.
   • Ejemplo: Los desarrolladores del lenguaje Go decidieron limitar el conjunto de funciones para que el lenguaje fuera más fácil de aprender y usar.

5. Código propio

   • En lugar de usar bibliotecas existentes, a veces tiene sentido escribir un código especializado para una tarea específica. Esto puede ser más rápido y eficiente, pero en algunos casos, como la criptografía, es mejor usar soluciones probadas.
   • Ventajas: El código propio puede ser más óptimo y rápido para una tarea específica.
   • Desventajas: Puede ser peligroso en áreas complejas, como la criptografía, donde los errores pueden llevar a problemas graves.

6. Optimización prematura

   • Se dice a menudo que la optimización prematura es perjudicial. Pero a veces, un poco de planificación y optimización al inicio pueden simplificar significativamente el trabajo posterior en un proyecto.
   • Planificación sabia: Es importante encontrar un equilibrio entre la optimización y la eficiencia en el desarrollo. A veces, una pequeña optimización al principio puede prevenir grandes problemas en el futuro.

7. Descuido

   • La verificación excesiva de datos puede ralentizar el código. A veces es mejor ignorar los instintos y escribir código que realice solo las verificaciones necesarias.
   • Ahorro de recursos: A veces se puede permitir menos verificaciones para mejorar el rendimiento del código. Pero esto debe justificarse y hacerse con precaución.

8. Inconsistencia

   • La uniformidad en el código lo hace más fácil de entender, pero requiere tiempo y esfuerzo. A veces es mejor aceptar cierta variedad en el código, especialmente si el proyecto depende de diferentes bibliotecas y API.
   • Realidad práctica: La uniformidad total a menudo es inalcanzable debido a diversas fuentes de código, como bibliotecas antiguas y API externas.

9. Perseguir nuevas funciones

   • Introducir nuevas funciones y bibliotecas puede romper patrones antiguos, pero este es el precio del progreso. A veces vale la pena arriesgarse e implementar nuevas capacidades.
   • Innovación: Agregar nuevas funciones y tecnologías puede requerir romper estándares antiguos, pero es necesario para el desarrollo y la mejora del proyecto.

10. Romper reglas

    • Los programadores a menudo rompen sus propias reglas. En la era de los grandes modelos de lenguaje y el aprendizaje automático, las reglas antiguas cambian. No siempre es necesario entender los algoritmos en detalle, a veces es suficiente confiar esta tarea a las máquinas.
    • Evolución de reglas: Con el desarrollo de las tecnologías, las reglas antiguas pueden quedar obsoletas. Los programadores deben adaptarse y estar listos para romper normas desactualizadas.

Los malos hábitos de programación no siempre son claros. Algunos pueden parecer negativos a primera vista, pero en ciertas condiciones pueden ser útiles y aumentar la eficiencia. Por ejemplo, la falta de comentarios puede estimular a los desarrolladores a escribir código más claro y autoexplicativo. El código lento, a pesar de sus desventajas obvias, a menudo resulta más robusto y fácil de mantener. Usar código antiguo o escribir el propio en lugar de bibliotecas puede mejorar el rendimiento en casos específicos.

Estos hábitos reflejan el proceso creativo de los programadores, que buscan equilibrar la eficiencia, el rendimiento y la mantenibilidad del código. Romper reglas a veces es un paso necesario para la innovación y el progreso. Es importante comprender el contexto y las consecuencias de tales decisiones para que sean beneficiosas y no perjudiciales.

Las tecnologías y los enfoques modernos en la programación continúan evolucionando, y junto con ellos también lo hacen las reglas. Los programadores deben estar listos para adaptarse y revisar sus métodos de trabajo. Al final, lo principal es crear software de calidad y confiable que resuelva las tareas planteadas y sea fácil de mantener a largo plazo.

Comprender y analizar sus hábitos permite a los programadores mejorar sus habilidades y enfoques, haciéndolos más flexibles y eficientes en un mundo tecnológico en constante cambio.