Este artículo está profundamente inspirado en Naming Things in Code del youtuber CodeAesthetic, a quien recomiendo ya que -aunque sus grabaciones estén en inglés- este muchacho es súper claro y comprensible. Además, sus videos y explicaciones son excelentes. Creo que ningún otro youtuber aborda los mismos temas que él. Por eso, los invito a ver sus otros videos, que están muy buenos y son verdaderamente recomendables.
¿Qué propone CodeAesthetic?
Como buen spoiler, les voy a enumerar algunos puntos que se describen en el video:
- No nombrar variables con una letra.
- Nunca abreviar.
- No poner tipos de datos en las variables.
- Usar unidades en las variables.
- Agregar tipos a los tipos de datos.
- No poner “Base” o “Abstract” a las clases.
- No codificar “Utils”.
Si ven la grabación, podrán encontrar los motivos dentro de cada una de estas sugerencias. Si me preguntan, yo estoy totalmente de acuerdo con todas ellas.
¿Qué les sumaría a estas sugerencias?
A continuación, agregaré algunos elementos de mi apreciación personal que se deben considerar al momento de nombrar cosas dentro de nuestro código. Muchos de ellos parecerán una obviedad, pero he visto una gran cantidad de códigos que no los tiene en cuenta ni en lo más mínimo.
1. Métodos y funciones
Los métodos de las clases y las funciones que utilicemos deberían tener verbos, porque las funciones y los métodos realizan acciones.
2. Evitar los “modificadores de Scope” (ejemplo g, m)
En algunos lenguajes legacy, era común ver la “g” al principio de una variable para indicar que era una variable global y “m” para indicar que era del módulo, etc. Según mi punto de vista, eso no tiene sentido ya que cada vez existen menos las variables “globales” o locales a un módulo, y nos apoyamos en los frameworks para almacenarlas. Generalizando un poco más, hay que evitar los prefijos y sufijos en general.
3. Demorar la declaración de variables lo máximo posible
Hoy en día, la mayoría de los lenguajes soporta “declaración tardía” de las variables, ya que el compilador/intérprete es el que realizará las optimizaciones según corresponda.
4. En los lenguajes que soporte “this”, utilizarlo para legibilidad
Creo que a pesar de que es discutible y debería ser indistinto, considero que aclara mucho al entender qué variables son del método, del objeto, etc. El mejor código es el que pueden leer humanos.
5. Color Highlight
Muchos editores permiten el color Highlight de los distintos scopes de las variables. A mí, esto me resulta sumamente útil.
6. Cuidado con el abuso de funciones/clases anónimas
¿Para qué nombrar variables si la tendencia es que cada vez haya más funciones y clases anónimas? Bueno, cuando vemos en nuestro código muchas anidaciones de funciones anónimas, creo que es momento de parar y preguntarse qué estamos haciendo.
En mi lenguaje base (Java), con los Streams, lo veo muchísimo. En JavaScript, con las Promise se puede hacer una ensalada terrible.
7. Separadores según el lenguaje
Estuve mirando un poco y según el lenguaje hay recomendaciones para el Camel Case, los separadores y las constantes en mayúsculas. Seguir las recomendaciones de acuerdo con el lenguaje o framework. Aquí, un link útil.
8. Escribirlas en inglés
No sabemos quién puede ver nuestro código después de nosotros y puede ser que gente del otro lado del mundo continúe nuestro código, o al revés. Me acuerdo que un compañero de la facultad me decía: “¿Cómo vas a poner el nombre en inglés? ¡Acá se habla español!”. Todo bien, hasta que vi comentarios y variables en hindi y no entendí nada.
El inglés es la lengua franca de la informática y utilizarla en un entorno multicultural como el de hoy en día, es muy buena práctica.
9. No mezclar con palabras reservadas
Parece sencillo en el código porque nuestro compilador/editor lo va a detectar como un error, pero cuando ese código “representa” una entidad de una base de datos, por ejemplo, poner ORDER a una clase, hará que tengamos que “escapear” el nombre si se persistiera en una base de datos. Sabemos dónde empieza nuestro código, pero no dónde o cuándo termina.
Excepción a la regla
Todas estas son sugerencias que podemos implementar en nuestro código con el objetivo de que sea más legible. Sin embargo, hay situaciones en las que realmente pueden obviarse ya que, en caso contrario, hará más complejo un código o un script.
