Aprender sin pensar es trabajo perdido; Pensar sin aprender es peligroso.
Los ninjas programadores del pasado usaban estos trucos para agudizar la mente de los encargados del mantenimiento del código.
Los gurús de la revisión de código los buscan en las tareas de prueba.
Los desarrolladores novatos a veces los utilizan incluso mejor que los programadores ninja.
Léelos atentamente y descubre quién eres: ¿un ninja, un novato o tal vez un revisor de códigos?
Ironía detectada
Muchos intentan seguir los caminos ninja. Pocos lo logran.
Haga el código lo más corto posible. Muestra lo inteligente que eres.
Déjate guiar por las sutiles funciones del lenguaje.
Por ejemplo, eche un vistazo a este operador ternario '?' :
// tomado de una conocida biblioteca javascript yo = yo? yo < 0 ? Math.max(0, len + i): i: 0;
Genial, ¿verdad? Si escribe así, un desarrollador que se encuentre con esta línea e intente comprender cuál es el valor de i se lo pasará muy bien. Entonces ven a ti en busca de una respuesta.
Dígales que lo más corto siempre es mejor. Inícialos en los caminos del ninja.
El Dao se esconde en el silencio. Sólo el Dao está bien iniciado y bien completado.
Otra forma de codificar de forma más breve es utilizar nombres de variables de una sola letra en todas partes. Como a , b o c .
Una variable corta desaparece en el código como un verdadero ninja en el bosque. Nadie podrá encontrarlo usando la “búsqueda” del editor. E incluso si alguien lo hace, no podrá “descifrar” lo que significa el b a .
…Pero hay una excepción. Un verdadero ninja nunca usará i como contador en un bucle "for" . En cualquier 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 contador de bucle es especialmente interesante si el cuerpo del bucle ocupa entre 1 y 2 páginas (alarguelo si puede). Entonces, si alguien mira profundamente dentro del bucle, no podrá darse cuenta rápidamente de que la variable llamada x es el contador del bucle.
Si las reglas del equipo prohíben el uso de nombres vagos y de una letra, acórtelos, haga abreviaturas.
Como esto:
list → lst .
userAgent → ua .
browser → brsr .
…etc
Sólo aquel que tenga una intuición verdaderamente buena podrá entender esos nombres. Intenta acortarlo todo. Sólo una persona digna debería poder mantener el desarrollo de su código.
La gran plaza no tiene esquinas.
El gran barco está completo por última vez,
La gran nota es sonido enrarecido,
La gran imagen no tiene forma.
Al elegir un nombre, intente utilizar la palabra más abstracta. Como obj , data , value , item , elem , etc.
El nombre ideal para una variable es data . Úselo en todos los lugares que pueda. De hecho, cada variable contiene datos , ¿verdad?
…Pero ¿qué hacer si ya se han tomado data ? Pruebe value , también es universal. Después de todo, una variable eventualmente obtiene un valor .
Nombra una variable por su tipo: str , num …
Pruébalos. Un joven iniciado puede preguntarse: ¿son esos nombres realmente útiles para un ninja? ¡De hecho, lo son!
Claro, el nombre de la variable todavía significa algo. Dice lo que hay dentro de la variable: una cadena, un número u otra cosa. Pero cuando un extraño intenta entender el código, se sorprenderá al ver que en realidad no hay ninguna información. Y, en última instancia, no logrará alterar su código bien pensado.
El tipo de valor es fácil de descubrir mediante la depuración. ¿Pero cuál es el significado de la variable? ¿Qué cadena/número almacena?
¡Simplemente no hay manera de descubrirlo sin una buena meditación!
…Pero ¿y si ya no existen esos nombres? Simplemente agregue un número: data1, item2, elem5 …
Sólo un programador verdaderamente atento debería poder comprender su código. ¿Pero cómo comprobar eso?
Una de las formas es utilizar nombres de variables similares, como date y data .
Mézclalos donde puedas.
Una lectura rápida de dicho código se vuelve imposible. Y cuando hay un error tipográfico… Ummm… Estamos atrapados por mucho tiempo, es hora de tomar té.
El Tao que se puede decir no es el Tao eterno. El nombre que se puede nombrar no es el nombre eterno.
Usar nombres similares para las mismas cosas hace la vida más interesante y muestra tu creatividad al público.
Por ejemplo, considere los prefijos de funciones. Si una función muestra un mensaje en la pantalla, iníciela con display… , como displayMessage . Y luego, si otra función muestra algo más en la pantalla, como un nombre de usuario, iníciela con show… (como showName ).
Insinúa que existe una sutil diferencia entre dichas funciones, cuando no la hay.
Haga un pacto con sus compañeros ninjas del equipo: si John comienza a "mostrar" funciones con display... en su código, entonces Peter podría usar render.. ... y Ann, paint... Observe cuánto más interesante y diverso se volvió el código.
…¡Y ahora el triplete!
Para dos funciones con diferencias importantes, ¡use el mismo prefijo!
Por ejemplo, la función printPage(page) utilizará una impresora. Y la función printText(text) pondrá el texto en pantalla. Deje que un lector desconocido piense detenidamente sobre la función printMessage con un nombre similar: “¿Dónde coloca el mensaje? ¿A una impresora o en la pantalla?”. Para que realmente brille, printMessage(message) debería mostrarlo en la nueva ventana.
Una vez dividido el todo, las partes
Necesito nombres.
Ya hay suficientes nombres.
Hay que saber cuándo parar.
Agregue una nueva variable solo cuando sea absolutamente necesario.
En su lugar, reutilice los nombres existentes. Simplemente escriba nuevos valores en ellos.
En una función intenta utilizar sólo variables pasadas como parámetros.
Eso haría que fuera realmente difícil identificar qué hay exactamente en la variable ahora . Y también de dónde viene. El objetivo es desarrollar la intuición y la memoria de la persona que lee el código. Una persona con intuición débil tendría que analizar el código línea por línea y rastrear los cambios en cada rama del código.
Una variante avanzada del enfoque es reemplazar de forma encubierta (!) el valor con algo similar en medio de un bucle o función.
Por ejemplo:
función función ninja(elem) {
// 20 líneas de código trabajando con elem
elem = clonar(elem);
// 20 líneas más, ¡ahora trabajando con el clon del elem!
} Un colega programador que quiera trabajar con elem en la segunda mitad de la función se sorprenderá... Sólo durante la depuración, después de examinar el código, descubrirá que está trabajando con un clon.
Visto en código regularmente. Mortalmente eficaz incluso contra un ninja experimentado.
Coloque guiones bajos _ y __ antes de los nombres de las variables. Como _name o __value . Sería fantástico si supieras su significado. O, mejor aún, agréguelos sólo por diversión, sin ningún significado particular. O diferentes significados en diferentes lugares.
Matas dos conejos de un solo disparo. En primer lugar, el código se vuelve más largo y menos legible y, en segundo lugar, un compañero desarrollador puede pasar mucho tiempo intentando descubrir qué significan los guiones bajos.
Un ninja inteligente pone guiones bajos en un lugar del código y los evade en otros lugares. Eso hace que el código sea aún más frágil y aumenta la probabilidad de errores futuros.
¡Que todos vean cuán magníficas son sus entidades! Nombres como superElement , megaFrame y niceItem definitivamente iluminarán al lector.
Efectivamente, por un lado se escribe algo: super.. , mega.. , nice.. Pero por el otro, eso no aporta ningún detalle. Un lector puede decidir buscar un significado oculto y meditar durante una o dos horas de su tiempo de trabajo remunerado.
Cuando hay luz, no puedo ver nada en la oscuridad.
Cuando está en la oscuridad, puede ver todo en la luz.
Utilice los mismos nombres para las variables dentro y fuera de una función. Tan simple. No hay esfuerzos por inventar nuevos nombres.
dejar usuario = autenticarUsuario();
función renderizar() {
let usuario = otroValor();
...
...muchas líneas...
...
... // <-- un programador quiere trabajar con el usuario aquí y...
...
} Un programador que salte dentro del render probablemente no se dará cuenta de que hay un user local siguiendo el exterior.
Luego intentarán trabajar con user asumiendo que es la variable externa, el resultado de authenticateUser() ... ¡La trampa ha saltado! Hola depurador...
Hay funciones que parece que no cambian nada. Como isReady() , checkPermission() , findTags() … Se supone que realizan cálculos, buscan y devuelven los datos, sin cambiar nada fuera de ellos. Es decir, sin “efectos secundarios”.
Un truco realmente bonito es añadirles una acción “útil”, además de la tarea principal.
Una expresión de sorpresa y aturdimiento en el rostro de su colega cuando ve una función llamada is.. , check.. o find... cambiando algo, definitivamente ampliará sus límites de razón.
Otra forma de sorprender es devolver un resultado no estándar.
¡Muestre su pensamiento original! Deje que la llamada de checkPermission no devuelva true/false , sino un objeto complejo con los resultados de la verificación.
Aquellos desarrolladores que intenten escribir if (checkPermission(..)) se preguntarán por qué no funciona. Dígales: "¡Lean los documentos!". Y regala este artículo.
El gran Tao fluye por todas partes,
tanto a la izquierda como a la derecha.
No limites la función por lo que está escrito en su nombre. Sea más amplio.
Por ejemplo, una función validateEmail(email) podría (además de verificar que el correo electrónico sea correcto) mostrar un mensaje de error y solicitar volver a ingresar el correo electrónico.
Las acciones adicionales no deberían ser obvias a partir del nombre de la función. Un verdadero codificador ninja tampoco hará que sean obvios en el código.
Unir varias acciones en una protege su código contra la reutilización.
Imagínese, otro desarrollador solo quiere revisar el correo electrónico y no enviar ningún mensaje. Su función validateEmail(email) que hace ambas cosas no les conviene. Para que no interrumpan tu meditación preguntándote algo al respecto.
Todos los “consejos” anteriores provienen del código real… A veces, escritos por desarrolladores experimentados. Quizás incluso más experiencia que tú ;)
Sigue algunos de ellos y tu código estará lleno de sorpresas.
Siga muchos de ellos y su código será verdaderamente suyo, nadie querrá cambiarlo.
Siga a todos y su código se convertirá en una lección valiosa para los desarrolladores jóvenes que buscan iluminación.