Programación Estilo Ninja
Pensar sin aprender es peligroso; aprender sin pensar es inútil.
Confucio (Analectas) Los programadores avanzados de antaño empleaban estos métodos para agudizar las habilidades de aquellos encargados del mantenimiento del código.
Los expertos en revisión de código buscan estos patrones en sus evaluaciones.
Los desarrolladores novatos a veces emplean estos métodos de forma más eficaz que los propios programadores experimentados.
Léelos con atención y descubre quién eres: ¿un ninja?, ¿un principiante?, ¿o quizás un revisor de código?
IRONÍA detectada
Muchos intentan seguir los pasos de los ninjas. Pocos lo logran.
La brevedad es el alma de la inteligencia
Haz el código lo más breve posible. Demuestra tu ingenio.
Deja que las peculiaridades del lenguaje te guíen.
Por ejemplo, mira este operador ternario ‘?’:
// tomado de una librería popular de JavaScript
i = i ? i < 0 ? Math.max(0, len + i) : i : 0;
Fascinante, ¿verdad? Si escribes de esa manera, cualquier desarrollador que se encuentre con esta línea y trate de entender el valor de i tendrá dificultades y probablemente vendrá a ti en busca de respuestas.
Diles que mientras más corto, mejor. Guíalos por el camino del ninja.
Variables de una sola letra
El Dao se oculta sin palabras. Solo el Dao está bien comenzado y bien terminado.
Laozi (Tao Te Ching) Otra forma de programar más rápido es utilizando variables de una sola letra en todas partes. Como a, b o c.
Una variable corta desaparece en el código como un ninja en el bosque. Nadie podrá encontrarla usando “buscar” en el editor. Y si alguien lo hace, no podrá descifrar el significado de a o b.
Pero hay una excepción. Un verdadero ninja nunca usaría i como el contador en un bucle «for». En cualquier otro lugar, pero no aquí. Mira a tu alrededor, hay muchas más letras exóticas. Por ejemplo, x o y.
Una variable exótica como el contador de un bucle es especialmente genial si el cuerpo del bucle ocupa 1-2 páginas (hazlo más largo si puedes). Entonces, si alguien mira en las profundidades del bucle, no será capaz de descifrar rápidamente que la variable llamada x es el contador del bucle.
Usa abreviaciones
Si las reglas del equipo prohíben el uso de nombres de una sola letra o nombres vagos, acórtalos, usa abreviaturas.
Como esto:
list→lst.userAgent→ua.browser→brsr.
Solo alguien con buena intuición será capaz de entender esos nombres. Intenta acortar todo. Solo una persona digna debería ser capaz de mantener el desarrollo de tu código.
Sé abstracto
El gran cuadrado no tiene esquina. La gran vasija se completa por última vez. La gran nota es un sonido raro. La gran imagen no tiene forma.
Laozi (Tao Te Ching) Cuando elijas un nombre, intenta usar la palabra más abstracta posible. Como obj, data, value, item, elem, etc.
El nombre ideal para una variable es data. Úsalo tanto como puedas. En efecto, toda variable contiene datos, ¿no?
Pero, ¿qué hacer si data ya está siendo utilizado? Intenta con value, también es universal. Después de todo, una variable eventualmente recibe un valor.
Nombra una variable por su tipo: str, num…
Pruébalos. Un recién iniciado podría preguntarse: ¿Son estos nombres realmente útiles para un ninja? En efecto, ¡lo son!
Claro, el nombre de la variable sigue significando algo. Indica qué hay en el interior de la variable: una cadena de texto, un número o cualquier otra cosa. Pero cuando alguien intenta entender el código, se verá sorprendido al ver que en realidad no hay información. Y finalmente fracasará en el intento de alterar tu código bien pensado.
El tipo de valor es fácil de encontrar con una depuración. Pero, ¿cuál es el significado de la variable? ¿Qué cadena de texto o número guarda?
¡No hay forma de saberlo sin una buena meditación!
Pero, ¿y si ya no hay más nombres de ese tipo? Simplemente añade un número: data1, item2, elem5…
Prueba de atención
Solo un programador realmente atento debería ser capaz de entender tu código. Pero, ¿cómo comprobarlo?
Una forma es usar nombres de variables similares, como date y data.
Combínalos donde puedas.
Una lectura rápida de dicho código se hace imposible. Y cuando hay un error de tipografía… Ummm… Estamos atrapados por mucho tiempo, hora de tomar té.
Sinónimos inteligentes
El Tao que puede ser expresado no es el Tao eterno. El nombre que puede ser nombrado no es el nombre eterno.
Laozi (Tao Te Ching) Usar nombres similares para las mismas cosas hace tu vida más interesante y muestra al público tu creatividad.
Por ejemplo, considera los prefijos de funciones. Si una función muestra un mensaje en la pantalla, comiénzala con mostrar, como mostrarMensaje. Y si otra función muestra otra cosa, como un nombre de usuario, comiénzala con presentar, como presentarNombre.
Insinúa que hay una diferencia sutil entre esas funciones, cuando no la hay.
Haz un pacto con tus compañeros ninjas del equipo: si John comienza funciones de “mostrar” con presentar en su código, entonces Peter podría usar exhibir, y Ann – pintar. Nota como el código es mucho más interesante y diverso ahora.
Y ahora, ¡el truco del sombrero!
Para dos funciones con diferencias importantes, ¡usa el mismo prefijo!
Por ejemplo, la función imprimirPagina(pagina) usará una impresora. Y la función imprimirTexto(texto) mostrará el texto en la pantalla… Deja que un lector no familiar con tu código piense sobre una función llamada de forma similar imprimirMensaje: «¿Dónde coloca el mensaje? ¿En una impresora o en la pantalla?». Para que realmente se destaque, ¡imprimirMensaje(mensaje) debería mostrar el mensaje en una nueva ventana!
Reutilizar nombres
Una vez que el todo se divide, las partes necesitan nombres. Ya hay suficientes nombres. Uno debe saber cuándo parar.
Laozi (Tao Te Ching) Añade una nueva variable solo cuando sea necesario.
En lugar de eso, reutiliza nombres que ya existen. Simplemente escribe nuevos valores en ellos.
En una función, intenta usar solo las variables pasadas como parámetros.
Eso hará que sea realmente difícil identificar qué es exactamente la variable ahora. Además de dónde viene. El propósito es desarrollar la intuición y memoria de la persona que lee el código. Una persona con intuición débil tendrá que analizar el código línea por línea y seguir los cambios en cada rama de código.
Una variante avanzada del enfoque es reemplazar los valores de forma encubierta con algo parecido en la mitad de un bucle o una función.
Por ejemplo:
function ninjaFunction(elem) {
// 20 líneas de código trabajando con elem
elem = clone(elem);
// 20 líneas más, ¡ahora trabajando con el clon de elem!
}
Un colega programador que quiera trabajar con elem en la segunda mitad de la función se sorprenderá… Solo durante la depuración, después de examinar el código, encontrará que está trabajando con un clon.
Visto regularmente en códigos. Letalmente efectivo, incluso contra ninjas experimentados.
Guiones bajos por diversión
Coloca guiones bajos _ y __ antes de los nombres de las variables. Como _name o __value. Sería genial si solo tú sabes su significado. O mejor, añádelos simplemente por diversión, sin ningún significado especial. O diferentes significados en diferentes lugares.
Matarás dos pájaros de un solo tiro. Primero, el código se hará más largo y menos legible, y segundo, un colega desarrollador podría gastar una gran cantidad de tiempo tratando de entender el significado del guion bajo.
Un ninja inteligente coloca los guiones bajos en un solo lugar del código y los evita en otros lugares. Eso hace que el código sea mucho más frágil y aumenta la probabilidad de errores futuros.
Muestra tu amor
Deja que todos vean cuán magníficas son tus entidades. Nombres como superElement, megaFrame y niceItem iluminarán sin duda al lector.
En efecto, por una parte, algo está escrito: super, mega, nice, pero por otra parte – no da ningún detalle. Un lector podría decidir buscar un significado oculto y meditar por una hora o dos.
Superpón variables externas
Cuando está a la luz, no puede ver nada en la oscuridad. Cuando está en la oscuridad, puede ver todo a la luz.
Guan Yin Zi Usa los mismos nombres para variables dentro y fuera de una función. Así de simple. Sin el esfuerzo de inventar nuevos nombres.
let user = authenticateUser();
function render() {
let user = anotherValue();
...
...many lines...
...
... // <-- un programador quiere trabajar con user aquí y...
...
}
Un programador que se adentra en render probablemente no notará que hay un user local opacando al de afuera.
Entonces intentarán trabajar con user asumiendo que es la variable externa, el resultado de authenticateUser(). ¡Se activa la trampa! Hola, depurador…
Efectos secundarios en todas partes
Hay muchas funciones que parecen no cambiar nada. Como isReady(), checkPermission(), findTags()… Se asume que realizan cálculos, encuentran y regresan datos, sin cambiar nada fuera de ellas. En otras palabras, sin “efectos secundarios”.
Un truco realmente bello es añadirles una acción “útil”, además de su tarea principal.
Una expresión de sorpresa aturdida aparecerá en la cara de tus colegas cuando vean que la función llamada is.., check.. o find... cambia algo. Definitivamente ampliará sus límites de razonamiento.
Otra forma de sorprender es retornar un resultado no estándar.
Muestra tu pensamiento original. Deja que la llamada de checkPermission retorne no true/false, sino un objeto complejo con los resultados de tu comprobación.
Funciones poderosas
El gran Tao fluye por todas partes, tanto a la izquierda como a la derecha.
Laozi (Tao Te Ching) No limites la función a lo que está escrito en el nombre. Sé más abierto.
Por ejemplo, una función validateEmail(email) podría, además de comprobar el email por exactitud, mostrar un mensaje de error y preguntar de nuevo por el email.
Las acciones adicionales no deberían ser obvias por el nombre de la función. Un verdadero programador ninja no las hará obvias por el código tampoco.
Uniendo muchas acciones en una sola función protege tu código de reúsos.
Imagina que otro desarrollador quiere solo comprobar el correo, y no mostrar ningún mensaje. Tu función validateEmail(email) que hace ambas cosas no le será de utilidad. Así que no romperán tu meditación preguntando cualquier cosa sobre ello.
Resumen
Todos los consejos anteriores fueron extraídos de código real, a veces escrito por desarrolladores experimentados. Quizás incluso más experimentados que tú.
Sigue alguno de ellos, y tu código estará lleno de sorpresas. Sigue muchos de ellos, y tu código será realmente tuyo, nadie querrá cambiarlo. Sigue todos, y tu código será una lección valiosa para desarrolladores jóvenes en busca de iluminación.
