El código corto no es muy importante en mi lista de cosas que no me gustan. De hecho, no está en la lista en absoluto; a menudo el código corto es demasiado inteligente y el código inteligente es difícil de depurar.
Tenemos un dicho en mi oficina: “tienes que ser más inteligente para depurar el código que escribirlo; si estás escribiendo el código más inteligente que puedas, entonces, por definición, no eres lo suficientemente inteligente como para depurarlo”. Probablemente no sea del todo cierto, como dicen los refranes, pero esa es mi actitud hacia un código demasiado inteligente.
Por otro lado, el código repetitivo es malo. Esto a menudo se vilipendia como código “copiar y pegar”. La razón es esta: casi cada pieza de código se va a cambiar eventualmente. Lo más común es corregir un error, pero también podría ser parte de la refactorización, la mejora de los comentarios, etc. Sea lo que sea, el código repetitivo es muy difícil de mantener . Esto se debe a que el cambio generalmente tiene que ocurrir en cada copia del código, y un programador de mantenimiento rara vez nota las otras copias. Si su código es largo porque es repetitivo, ¡trate de encontrar formas de evitar la repetición! Por lo general, es mejor dividir la parte repetida en una función y luego llamar a la función en cada punto donde se copió el código original. ¡Esto suele ser cierto incluso si el segmento repetido solo se usa dos veces!
- ¿Podría haber un límite superior en la 'inteligencia' de una IA?
- ¿Cuáles son algunas aplicaciones prácticas de los árboles AVL y los árboles de separación?
- ¿Por qué el cifrado de la función Algoritmo de hash no puede transformar el texto cifrado en texto sin formato?
- ¿Cuánto tiempo / horas debo pasar todos los días para ser un buen programador de Java para poder resolver estructuras de datos y algoritmos con ese lenguaje en el futuro?
- Cómo probar la profundidad del primer recorrido utilizando listas de adyacencia
No es la longitud del código, sino la claridad del código y la facilidad de mantenimiento lo que importa. Si los nombres de sus variables y funciones dejan en claro cuáles son sus significados y unidades, bien. Si su código incluye pruebas automatizadas que exploran a fondo todos los casos, incluidas todas las condiciones de error, excelente. Si su código incluye comentarios que me ayudan a comprender sus intenciones (no solo lo que hace el código, sino lo que pretende que haga y por qué), excelente. Dicho código es fácil de modificar y es fácil distinguir los errores de las peculiaridades necesarias.
El código sucinto es mejor que el código largo si todo lo demás es igual. Pero tomaré una función larga y legible durante un breve estallido de sopa de puntuación cada vez.
