13 puntos notables de la guía de estilo JavaScript de Google

Para cualquiera que no esté familiarizado con él, Google ofrece una guía de estilo para escribir JavaScript que presenta (lo que Google cree que son) las mejores prácticas estilísticas para escribir código limpio y comprensible.

Estas no son reglas estrictas y rápidas para escribir JavaScript válido, solo proscripciones para mantener opciones de estilo consistentes y atractivas en todos los archivos de origen. Esto es particularmente interesante para JavaScript, que es un lenguaje flexible y tolerante que permite una amplia variedad de opciones estilísticas.

Google y Airbnb tienen dos de las guías de estilo más populares que existen. Definitivamente te recomiendo que revises ambos si pasas mucho tiempo escribiendo JS.

Las siguientes son trece de las que creo que son las reglas más interesantes y relevantes de la Guía de estilo JS de Google.

Se ocupan de todo, desde cuestiones muy controvertidas (tabulaciones frente a espacios y la controvertida cuestión de cómo se deben usar los puntos y comas), hasta algunas especificaciones más oscuras que me sorprendieron. Definitivamente cambiarán la forma en que escribo mi JS en el futuro.

Para cada regla, daré un resumen de la especificación, seguido de una cita de apoyo de la guía de estilo que describe la regla en detalle. Cuando corresponda, también proporcionaré un ejemplo del estilo en la práctica y lo contrastaré con el código que no sigue la regla.

Usa espacios, no pestañas

Aparte de la secuencia del terminador de línea, el carácter de espacio horizontal ASCII (0x20) es el único carácter de espacio en blanco que aparece en cualquier lugar de un archivo fuente. Esto implica que… Los caracteres de tabulación no se utilizan para la sangría.

La guía luego especifica que debe usar dos espacios (no cuatro) para la sangría.

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

Se requieren puntos y comas

Cada declaración debe terminar con un punto y coma. Está prohibido confiar en la inserción automática de punto y coma.

Aunque no puedo imaginar por qué alguien se opone a esta idea, el uso constante de punto y coma en JS se está convirtiendo en el nuevo debate de 'espacios versus pestañas'. Google está saliendo con firmeza aquí en defensa del punto y coma.

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

No use módulos ES6 (todavía)

No utilice los módulos ES6 todavía (es decir, las palabras clave exporty import), ya que su semántica aún no está finalizada. Tenga en cuenta que esta política se revisará una vez que la semántica sea completamente estándar.
// Don't do this kind of thing yet:
//------ 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';

Se desaconseja la alineación horizontal (pero no se prohíbe)

Esta práctica está permitida, pero Google Style la desaconseja en general . Ni siquiera es necesario mantener la alineación horizontal en lugares donde ya se usó.

La alineación horizontal es la práctica de agregar un número variable de espacios adicionales en su código, para hacer que ciertos tokens aparezcan directamente debajo de otros tokens en líneas anteriores.

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

Ya no uses var

Declare todas las variables locales con consto let. Utilice const de forma predeterminada, a menos que sea necesario reasignar una variable. La varpalabra clave no debe ser utilizado.

Todavía veo personas que usan varmuestras de código en StackOverflow y en otros lugares. No puedo decir si hay gente ahí fuera que lo defienda, o si es solo un caso de viejos hábitos que están muriendo.

// badvar example = 42;
// goodlet example = 42;

Se prefieren las funciones de flecha

Las funciones de flecha proporcionan una sintaxis concisa y solucionan una serie de dificultades this. Prefiere las funciones de flecha sobre la functionpalabra clave, particularmente para funciones anidadas

Seré honesto, pensé que las funciones de flecha eran excelentes porque eran más concisas y agradables de ver. Resulta que también cumplen un propósito bastante importante.

// bad[1, 2, 3].map(function (x) { const y = x + 1; return x * y;});// good[1, 2, 3].map((x) => { const y = x + 1; return x * y;});

Utilice cadenas de plantilla en lugar de concatenación

Utilice cadenas de plantilla (delimitadas con `) sobre la concatenación de cadenas complejas, especialmente si se trata de varios literales de cadena. Las cadenas de plantillas pueden abarcar varias líneas.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction sayHi(name) { return `How are you, ${name}?`;}

No use continuaciones de línea para cadenas largas

No utilice continuaciones de línea (es decir, terminar una línea dentro de un literal de cadena con una barra invertida) en literales de cadena ordinarios o de plantilla. Aunque ES5 permite esto, puede dar lugar a errores complicados si algún espacio en blanco final viene después de la barra y es menos obvio para los lectores.

Curiosamente, esta es una regla en la que Google y Airbnb no están de acuerdo (aquí está la especificación de Airbnb).

Si bien Google recomienda concatenar cadenas más largas (como se muestra a continuación), la guía de estilo de Airbnb recomienda esencialmente no hacer nada y permitir que las cadenas largas continúen el tiempo que sea necesario.

// bad (sorry, this doesn't show up well on mobile)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.';
// goodconst 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.';

"Para ... de" es el tipo preferido de "bucle for"

Con ES6, el idioma ahora tiene tres tipos diferentes de forbucles. Todo se puede utilizar, sin embargo for- ofbucles deben ser preferidos cuando sea posible.

Este es extraño si me preguntas, pero pensé en incluirlo porque es bastante interesante que Google declare un tipo de forbucle preferido .

Siempre tuve la impresión de que los for... inbucles eran mejores para los objetos, mientras que for... ofse adaptaban mejor a las matrices. Una situación de tipo "herramienta adecuada para el trabajo adecuado".

Si bien la especificación de Google aquí no necesariamente contradice esa idea, sigue siendo interesante saber que tienen una preferencia por este bucle en particular.

No use eval ()

No utilice evalo el Function(...string)constructor (excepto para cargadores de código). Estas características son potencialmente peligrosas y simplemente no funcionan en entornos CSP.

La página de MDN para eval()even tiene una sección llamada "¡No use eval!"

// badlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"eval( 'var result = obj.' + propName );
// goodlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

Las constantes deben nombrarse en ALL_UPPERCASE separadas por guiones bajos

Uso de nombres constantes CONSTANT_CASE: todas letras mayúsculas, con palabras separadas por guiones bajos.

Si está absolutamente seguro de que una variable no debería cambiar, puede indicarlo escribiendo en mayúscula el nombre de la constante. Esto hace que la inmutabilidad de la constante sea obvia a medida que se usa en todo el código.

Una excepción notable a esta regla es si la constante tiene un ámbito de función. En este caso, debería estar escrito en camelCase.

// badconst number = 5;
// goodconst NUMBER = 5;

Una variable por declaración

Cada declaración de variable local declara solo una variable: declaraciones como let a = 1, b = 2;no se utilizan.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Utilice comillas simples, no dobles

Los literales de cadena ordinarios se delimitan con comillas simples ( '), en lugar de comillas dobles ( "). Consejo: si una cadena contiene un carácter de comilla simple, considere usar una cadena de plantilla para evitar tener que escapar de la comilla.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

Una nota final

Como dije al principio, estos no son mandatos. Google es solo uno de los muchos gigantes tecnológicos, y estas son solo recomendaciones.

Dicho esto, es interesante observar las recomendaciones de estilo que ofrece una empresa como Google, que emplea a muchas personas brillantes que pasan mucho tiempo escribiendo un código excelente.

You can follow these rules if you want to follow the guidelines for ‘Google compliant source code’ — but, of course, plenty of people disagree, and you’re free to brush any or all of this off.

I personally think there are plenty of cases where Airbnb’s spec is more appealing than Google’s. No matter the stance you take on these particular rules, it is still important to keep stylistic consistency in mind when write any sort of code.