Google publica una guía de estilo JavaScript. Aquí las lecciones clave
Para todos aquellos que no lo sepáis, Google publica una guía de estilo (en inglés) para JavaScript que muestra las mejores (en opinión de Google) prácticas para escribir código limpio y comprensible.
No son reglas estrictas para escribir código JavaScript válido, sino sugerencias para mantener un estilo consistente y legible en nuestro código. Eso es especialmente interesante para JavaScript, ya que es un lenguaje bastante flexible y permisivo que permite una gran variedad de estilos.
Google y Airbnb (en inglés) tienen dos de las guías disponibles más populares. Os recomendamos que consultéis ambas si escribís JavaScript a menudo.
Las siguientes son trece de las que considero las reglas más interesantes y relevantes de la guía de estilo JavaScript de Google.
Tratan todos los asuntos, desde temas muy discutidos (espacios o tabuladores, y el uso de punto y coma) hasta especificaciones menos claras que me sorprendieron. Seguro que cambiarán la forma en que escribimos JavaScript desde ahora.
Para cada regla, daremos un resumen de las especificación, seguido de un ejemplo de la guía que describe la regla en detalle. Donde sea posible aplicarlo, proporcionaremos un ejemplo de estilo en la práctica y lo contrastaremos con un ejemplo que no sigue la regla.
Usa espacios, no tabuladores
Aparte del fin de línea, el carácter ASCII de espacio horizontal (0x20) es el único espacio de carácter en blanco que aparece en el código. Eso implica que… los caracteres de tabulación no se usan para identar.
La guía especifica también que debemos usar dos espacios (y no cuatro) para identar.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// mal function foo() { ∙∙∙∙let name; } // mal function bar() { ∙let name; } // bien function baz() { ∙∙let name; } |
El punto y coma ES obligatorio
Cada sentencia debe terminar con un punto y coma. Depender de la inserción automática del punto y coma esta prohibido.
Aunque puedo imaginar que alguien se oponga a esta idea, el uso consistente de puntos y coma en JavaScript se está convirtiendo en el nuevo debate «tabuladores contra espacios».
|
1 2 3 4 5 6 7 8 9 10 11 |
// mal let luke = {} let leia = {} [luke, leia].forEach(jedi => jedi.father = 'vader') // bien let luke = {}; let leia = {}; [luke, leia].forEach((jedi) => { jedi.father = 'vader'; }); |
No usar módulos ES6 (aún)
No uses los módulos ES6 todavía (es decir, import y export), ya que su semántica aún no está finalizada. Ten en cuenta que esta regla será revisada cuando la semántica sea completamente estándar.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// No hagas esto aún: //------ lib.js ------ export function square(x) { return x * x; } export function diag(x, y) { return sqrt(square(x) + square(y)); } //------ main.js ------ import { square, diag } from 'lib'; |
El alineamiento horizontal está desaconsejado (pero no prohibido)
Esta práctica está permitida, pero generalmente desaconsejada por el estilo de Google. Ni tan sólo se requiere mantener la alineación horizontal en lugares donde ya se usaba.
La alineación horizontal es la práctica de usar un número variable de espacios adicionales en el código, para que ciertos elementos aparezcan justo debajo de otros elementos de las líneas anteriores.
|
1 2 3 4 5 6 7 8 9 10 11 |
// mal { tiny: 42, longer: 435, }; // bien { tiny: 42, longer: 435, }; |
Deja de usar var
Declara todas las variables locales con const o let. Usa const por defecto, a menos que la variable vaya a ser reasignada. La palabra clave var no debe usarse.
Aún vemos a gente usar var en ejemplos de código en StackOverflow y otros lugares. No estoy seguro de que se trate de gente que quiere crear una nueva controversia o simplemente son hábitos que cuesta cambiar.
|
1 2 3 4 5 |
// mal var example = 42; // bien let example = 42; |
Usar preferentemente funciones flecha (arrow)
Las funciones flecha proporcionan una sintaxis concisa y solucionan varias dificultades de this. Prioriza las funciones flecha sobre la palabra clave function, especialmente en funciones anidadas.
Sinceramente, pensaba que las funciones flecha eran mejores por que son más concisas y tienen mejor aspecto. Pero es que además tienen un propósito muy importante.
|
1 2 3 4 5 6 7 8 9 10 11 |
// mal [1, 2, 3].map(function (x) { const y = x + 1; return x * y; }); // bien [1, 2, 3].map((x) => { const y = x + 1; return x * y; }); |
Usa plantillas de strings en lugar de concatenar
Usa plantillas de strings (delimitadas por `) en lugar de concatenaciones complejas de strings, especialmente si están involucrados varios literales. Las plantillas de strings puede usarse en varias líneas.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// mal function sayHi(name) { return 'How are you, ' + name + '?'; } // mal function sayHi(name) { return ['How are you, ', name, '?'].join(); } // mal function sayHi(name) { return `How are you, ${ name }?`; } // bien function sayHi(name) { return `How are you, ${name}?`; } |
No usar continuaciones para strings largos
No uses continuaciones de línea (es decir, terminar una línea dentro de un literal string con una contrabarra) ni en plantillas de literales string ni normales. Aunque ES5 lo permite, puede llevarnos a errores si un blanco de final de línea viene después de la barra, y es difícil de detectar.
Como curiosidad, Google y Airbnb discrepan en esta regla (aquí la especificación de Airbnb (en inglés)).
Mientras que Google recomienda concatenar strings largos (como veremos abajo), la guía de estilo de Airbnb recomienda esencialmente no hacer nada, y permitir que los strings largos sigan hasta donde lo necesiten.
|
1 2 3 4 5 6 7 8 9 10 11 |
// mal (puede que no se vea bien en móvil) const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.'; // bien const longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.'; |
«for… of» es el tipo preferente de iteración for
Con ES6, el lenguaje tiene ahora tres tipos diferentes de iteración for. Pueden usarse todas, aunque el tipo «for-of» debe ser el preferente cuando sea posible.
Esta es una norma extraña a mi parecer, pero he pensado en incluirla porque es bastante interesante que Google declare un tipo preferente para iteraciones for.
Siempre he tenido la impresión de que las iteraciones for...in eran mejores para objetos, mientras que for...of eran mejores para arrays. Una situación del tipo ‘herramienta correcta para cada situación’.
Aunque la especificación de Google no contradice necesariamente esta idea, es interesante conocer que tienen una preferencia por este tipo de iteración en particular.
No usar eval()
No usar eval o el constructor Function(…string) (excepto para cargadores de código). Estas características son potencialmente peligrosas y sencillamente no funcionan en entornos CSP.
La página MDN (en inglés) para eval() incluso tiene una sección llamada «¡No uses eval!».
|
1 2 3 4 5 6 7 8 9 |
// mal let obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" eval( 'var result = obj.' + propName ); // bien let obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a |
Los nombres de constantes serán en mayúsculas y separadas por guión bajo
Los nombres de constantes usarán CONSTANT_CASE: todas las letras mayúsculas, con palabras separadas por guión bajo.
Si estás absolutamente seguro de que el valor de una variable no va a cambiar, puedes indicarlo poniendo en mayúsculas el nombre de la constante. Esto hace que su inmutabilidad sea obvia en todo el código.
Una excepción a esta regla es cuando el ámbito de esa constante es una función. En ese caso, debería escribirse en camelCase.
|
1 2 3 4 5 |
// mal const number = 5; // bien const NUMBER = 5; |
Una variable por declaración
Cada declaración de variable local declara una sola variable: declaraciones como let a = 1, b = 2; no se usan.
|
1 2 3 4 5 6 7 |
// mal let a = 1, b = 2, c = 3; // bien let a = 1; let b = 2; let c = 3; |
Usa comillas simples, no dobles
Los literales de cadena se delimitan con comillas simples (‘) no con comillas dobles («).
Consejo: si un string contiene una comilla sencilla, considera usar una plantilla para evitar tener que escapar la comilla.
|
1 2 3 4 5 6 7 8 9 10 11 |
// mal let directive = "No identification of self or mission." // mal let saying = 'Say it ain\u0027t so.'; // bien let directive = 'No identification of self or mission.'; // bien let saying = `Say it ain't so`; |
Una nota final
Como hemos dicho al inicio, esto no son mandatos. Google es sólo uno de los gigantes tecnológicos y estas son sólo sus recomendaciones.
Dicho esto, es interesante observar las recomendaciones de estilo que publica una compañía como Google, que da empleo a mucha gente brillante y que pasa mucho tiempo escribiendo código excelente.
Puedes seguir estas reglas si quieres seguir la línea de ‘código fuente de Google’ – pero, naturalmente, mucha gente no está de acuerdo y eres libre de obviarlas parcial o totalmente.
Personalmente creo que hay muchos casos donde las especificaciones de Airbnb son más atractivas que las de Google. Sin importar que decisiones tomes sobre estas reglas, es importante tener un código de estilo consistente cuando escribimos código
Nota: puedes encontrar el artículo original en https://medium.freecodecamp.org/google-publishes-a-javascript-style-guide-here-are-some-key-lessons-1810b8ad050b