Esta es la traducción de un artículo del sitio javascript.info, y pueden visitar el artículo original si quieren leerlo en inglés.
Aprender sin pensar es trabajo perdido: pensar sin aprender es peligroso. Confucious
Los programadores ninjas del pasado usaban estos trucos para cambiar la mente de los demás desarrolladores.
Los revisadores de código los buscan.
Los desarrolladores novatos algunas veces los usan incluso mejor que los programadores ninjas.
Lee cuidadosamente y descubre quién eres: un ninja, un novato o tal vez un revisador de código.
Has el código tan corto como puedas. Muestra cuán inteligente eres.
Deja que las sutilezas de las funcionalidades del lenguaje te guíen.
Por ejemplo, mira el operador ternario '?'
:
// taken from a well-known javascript library
i = i ? i < 0 ? Math.max(0, len + i) : i : 0;
Increible, no? Si tu codificas de esa manera, cualquiera que se encuentre con esa línea y trate de entender cual es el valor de i
, va a tener un buen momento. Al final terminará viniendo a ti, buscando por una respuesta.
Diles que corto siempre es mejor. Iniciarlos en el camino del ninja.
El Dao se esconde en el sin palabras. Solo el Dao es bien comenzado y bien terminado. Laozi (Tao Te Ching)
Otra manera de codificar poco, es usar variables con una sola letra de nombre en todos lados. Ejemplo a
, b
y c
.
Una variable de nombre corto, desaparece en el código como un ninja real en el bosque. Nadie será capaz de encontrarlas incluso usando el "buscar" del editor. Incluso si alguien la encuentra, no será capaz de "descifrar" que significa el nombre a
o b
.
...Pero hay una excepción. Un ninja real nunca usará i
como contador en un ciclo for
. En cualquier lado, pero no ahí. Busca por ahí, hay muchas más letras exóticas. Ejemplo x
o y
.
Una variable exótica como un contador en un ciclo es especialmente genial si el cuerpo del ciclo es de 1-2 páginas (has el ciclo tan grande como puedas). Entonces si alguien mira con detenimiento el ciclo, no será capaz de fácilmente entender que la variable x
es el contador del ciclo.
Si las reglas del equipo prohiben el uso de variables de una sola letra y nombres cortos - acórtalos, has abreviaciones.
Ejemplo:
list
-> lst
.userAgent
-> ua
.browser
-> brsr
.Solo aquellos con buena intuición serán capaces de entender semejantes nombres. Intenta acortar todo. Solo una persona digna será capaz de mantener el desarrollo de tu código.
La gran plaza no tiene esquinas. El gran barco está completo. La gran nota ratifica el sonido. La gran imagen no tiene forma. Laozi (Tao Te Ching)
Mientras elijas un nombre trata de usar las palabras más abstractas. Cómo obj
, data
, value
, item
, elem
y muchas más.
El nombre ideal para las variables es data
. úsalo en todas las partes que puedas. En efecto, toda variable tiene datos, verdad?
...Pero qué hacer si data
ya fue usado? Pues intentalo con value
, es también algo universal. Después de todo, una variable eventualmente tendrá un valor.
Nombra una variable por su tipo: str
, num
...
Dales una oportunidad. Una iniciativa joven debe prevalecer - son estos nombres realmente necesarios para un ninja? en efecto, lo son!
Claramente, el nombre de una variable significa algo. Esto dice que hay dentro de la variable: una cadena, un número o algo más. Pero cuando alguien externo intente entender el código, ellos se sorprenderán al ver que realmente no informan nada! y en última instancia fallarán al alterar tu buen código.
El tipo de valor es fácil de encontrar debugueando. Pero cuál es el significado de la variable? Qué string/number almacena?
No hay manera de adivinar sin una buena meditación!
...Pero qué pasa si ya no hay más de esos nombres? pues adiciona números al final: data1, item2, elem5
...
Solo un verdadero y atento programador será capaz de entender tu código. Pero cómo estar seguro de esto?
Una de las maneras - usa nombres de variables similares, como date
y data
.
O mézclalos cuando puedas.
Una rápida mirada a dicho código será imposible. Y cuando hay una falta de ortografía... Ummm... Estamos estancados por largo rato, tiempo para un té.
Lo más dificil de todo, es encontrar un gato negro en una habitación oscura, especialmente si no hay gato. Confucius
Usar nombres similares para la misma cosa hace la vida más interesante y muestra tu creatividad a los demás.
Por ejemplo, considera los prefijos de las funciones. Si una función muestra un mensaje en la pantalla - empieza esta con display...
, como displayMessage
. Y si otra función muestra otra cosa en la pantalla, como el nombre, comiénzala con show...
(como showName
).
Deja en entredicho que hay una sutil diferencia entre ambas funciones, mientras no la haya.
Haz un pacto con tus compañeros ninjas del equipo: si John empieza las funciones de "mostrar" con display...
en el código, entonces Peter puede usar render...
, y Ann - paint...
. Nótese cuánto más interesante se ha convertido el código.
...y ahora el truco del sombrero!
Para dos funciones con diferencias importantes - usa el mismo prefijo!
Por ejemplo, la función printPage(page)
puede usar la impresora. Y la función printText(text)
puede poner un texto en pantalla. Deja a los desarrolladores no familiarizados con el código pensarselo bien sobre funciones nombradas igual printMessage
: "Dónde pondrá el mensaje? A la impresora o en la pantalla?". Para hacerlo que realmente brille, printMessage(message)
debería mostrar el mensaje en una nueva ventana!
Una vez que todo está dividido, las partes necesitan nombre. Hay realmente suficientes nombres. Uno debe saber cuando detenerse. Laozi (Tao Te Ching)
Adiciona nuevas variables solo cuando sea absolutamente necesario.
En efecto, reusa nombres existentes. Solo asígnales nuevos valores a estos.
Si estás en una función, trata de usar solo las variables pasadas como parámetros.
Esto hará bien difícil la tarea de identificar qué exactamente hay en la variable. Y también de dónde viene. El propósito es desarrollar la intuición y la memoria de la persona que está revisando el código. Una persona con poca intuición tendrá que analizar el código línea a línea y rastrear los cambios a través de cada rama del código.
Un variante avanzada de esto, es encubiertamente(!) reemplazar el valor con algo completamente diferente en el medio de un ciclo o de una función.
Por ejemplo:
function ninjaFunction(elem) {
// 20 lines of code working with elem
elem = clone(elem);
// 20 more lines, now working with the clone of the elem!
}
Un compañero programador que quiera trabajar con elem
en la segunda mitad de la función, quedará sorprendido... Solo mientras debuguee, después de examinar el código, podrá encontrar que está trabajando con un clone!
Visto en código regularmente. Mortalmente efectivo incluso para ninjas experimentados.
Pon underscores _
y __
antes de los nombres de las variables. Cómo _name
o __value
. Esto será genial si solo tu sabes el significado. O, incluso mejor, adiciona esto solo por gracia, sin ningún significado en particular. O por diferentes significados en diferentes lugares.
Matarás dos pájaros de un tiro. Primero, el código se convertirá en más largo y en menos entendible, y la segunda, un compañero puede gastar un buen tiempo tratando de entender qué significan los underscores.
Un ninja inteligente pone underscores en una parte del código y evade estos en los demás lugares. Esto hace el código incluso más frágil y aumenta la probabilidad de futuros errores.
Deja que todos vean cuán magnífica es tu entidad! Nombres cómo superElement
, megaFrame
y niceItem
harán definitivamente asombrarse al lector.
En efecto, por una parte, algo escrito cómo: super...
, mega...
, nice...
Pero por otra parte - que no brinde ningún detalle. El lector probablemente decidirá buscar por algún significado oculto y meditará por una hora o dos de su tiempo (pagado) de trabajo.
Cuando en la luz, no puedes ver nada en la oscuridad. Cuando en la oscuridad, puedes ver todo en la claridad. Guan Yin Zi
Usa los mismo nombres de variables dentro y fuera de una función. Así de simple. Sin esfuerzo en inventar nuevos nombres.
let user = authenticateUser();
function render() {
let user = anotherValue();
...
...many lines...
...
... // <-- a programmer wants to work with user here and...
...
}
Un programador que esté dentro de la función render
, probablemente no notará que hay una variable local user
suplantando la variable externa.
Entonces ellos intentarán trabajar con user
asumiendo que es la variable externa, el resultado de authenticateUser()
...Ha caído en la trampa! Hola, debuguer...
Hay funciones que parecen que no cambian nada. Cómo isReady()
, checkPermission()
, findTags()
... Se asume que solo tienen cálculos, buscan y retornan datos, sin cambiar nada fuera de ellos. En otras palabras, sin "efectos colaterales".
Un hermoso truco es adicionar una "útil" acción a estos, además de su tarea principal
La expresión de aturdimiento y sorpresa en la cara de tus colegas cuando vean una función nombrada is...
, check...
o find...
que cambie algo - definitivamente ampliará tus fronteras de la razón.
Otra manera de sorprender, es retornando un resultado no estandar
Muestra tu pensamiento original! Deja que la llamada a la función checkPermission
retorne no un true/false
, sino un objeto complejo con el resultado de la comprobación.
Estos desarrolladores que traten de escribir if (checkPermission(...))
, se preguntarán por qué no funciona. Diles: "Leanse la documentación". Y denle este artículo.
El gran flujo Tao en todos lados, tanto a la izquierda como a la derecha. Laozi (Tao Te Ching)
No limites la función a lo que está escrito en su nombre. Se más amplio.
Por ejemplo, la función validateEmail(email)
puede (además de validar el correo) mostrar un mensaje de error y preguntar por la re-escritura del correo.
Acciones adicionales no deben ser obvias a partir del nombre de la función. En el código de un verdadero ninja esto no es obvio tampoco.
Unir varias acciones dentro de una, protegerán tu código de ser reusable
Imagínense, otro desarrollador que quiera solo comprobar el correo y no mostrar ningún mensaje. Tu función validateEmail(email)
que hace ambas cosas, no servirá para ninguna. Entonces ellos no romperán tu meditación para preguntar nada acerca de esto.
Todos "los consejos" de arriba vienen de códigos reales... Algunas veces escritos por desarrolladores experimentados. Algunas veces más experimentados que tu ;)
Sigue algunos de los consejos, y tu código estará lleno de sorpresas.
Sigue muchos de estos consejos, y tu código será verdaderamente tuyo, nadie querrá cambiarlo.
Sigue todos los consejos, y tu código se convertirá en una lección invaluable para los jóvenes desarrolladores buscando por iluminación.
Happy coding!