¿Qué especificaciones de código JS ha publicado Google?
Esta vez les traeré las especificaciones del código JS publicadas por Google y cuáles son las precauciones al usar las especificaciones del código JS publicadas por Google. El siguiente es un caso práctico, echemos un vistazo.
Google ha lanzado una especificación de código JS para aquellos que no están familiarizados con las especificaciones de codificación. Enumera las mejores prácticas para escribir código conciso y comprensible.
La especificación del código no es una regla para escribir código JavaScript correcto, sino una opción para mantener consistente el patrón de escritura del código fuente. Esto es especialmente cierto para el lenguaje JavaScript, ya que es flexible y menos restrictivo, lo que permite a los desarrolladores utilizar muchos estilos de codificación diferentes.
Google y Airbnb representan cada uno la mitad de los estándares de codificación más populares. Si va a invertir mucho tiempo en escribir código JS, le recomiendo encarecidamente que lea los estándares de codificación de estas dos empresas.
Lo que quiero escribir a continuación son las trece reglas que personalmente creo que están estrechamente relacionadas con el desarrollo diario de las especificaciones del código de Google.
Los temas que tratan son muy controvertidos, incluyendo tabulaciones y espacios, si se debe forzar el uso de punto y coma, etc. También hay algunas reglas que me sorprenden y muchas veces terminan cambiando mis hábitos al escribir código JS.
Para cada regla, primero daré un resumen de la especificación y luego citaré la descripción detallada de la especificación. También daré algunos contraejemplos apropiados para demostrar la importancia de seguir estas reglas.
Utilice espacios en lugar de tabulaciones. Además de la secuencia de terminación de cada línea, el carácter de espacio horizontal ASCII (0x20) es el único carácter de espacio que puede aparecer en cualquier parte del archivo fuente. Esto también significa que el carácter de tabulación no debe usarse ni usarse para controlar la sangría.
La especificación establece posteriormente que la sangría debe lograrse utilizando 2 espacios en lugar de 4.
// malo
función foo() {
let name;
}
// malo
barra de funciones() { let nombre
}
// bueno
función baz() { let nombre;
p>
}El punto y coma no se puede omitir. Cada declaración debe terminar con un punto y coma. No se permite confiar en la capacidad de JS para agregar punto y coma automáticamente.
Aunque no entiendo por qué alguien objetaría esta regla, el uso de punto y coma aparentemente se ha vuelto tan controvertido como el tema "espacios versus tabulaciones". Google dijo que el punto y coma es necesario y no se puede omitir.
// malo
let luke = {}
let leia = {}
[luke, leia].forEach(jedi =gt; jedi.father = 'vader')
// bueno
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) =gt; {
jedi.father = 'vader';
}); No utilice el módulo ES6 para Por el momento, debido a que la semántica de los módulos ES6 aún no está completamente definida, por lo tanto, no utilice palabras clave como exportar e importar todavía. Una vez finalizadas sus especificaciones, ignore esta regla.
// No escribas el siguiente código todavía:
//------ lib.js ------
función de exportación cuadrado (x) {
return x * x;
}
exportar función diag(x, y) {
return sqrt ( cuadrado(x) cuadrado(y));
}
//------ main.js ------
import { square, diag } from 'lib'; Nota del traductor: No parece realista cumplir con esta especificación, después de todo, Babel ya existe. Y al utilizar React, la mejor práctica es utilizar módulos ES6.
No se recomienda la alineación horizontal del código. Las especificaciones de código de Google permiten, pero no recomiendan, la alineación horizontal del código. Incluso si la alineación horizontal se realizó en el código anterior, este comportamiento debería evitarse en el futuro.
Alinear su código horizontalmente agrega espacios en blanco adicionales al código, haciendo que los caracteres en dos líneas adyacentes parezcan alineados verticalmente.
// malo
{
diminuto: 42,
más largo: 435,
};
// bueno
{
diminuto: 42,
más largo: 435,
}; Utilice const o let para declarar todas las variables locales. Si no es necesario reasignar la variable, se debe utilizar const de forma predeterminada. Se debe rechazar el uso de la palabra clave var.
No sé si es porque nadie puede convencerlos o si es porque los viejos hábitos cuestan morir. Actualmente todavía veo muchas personas que usan var para declarar variables en StackOverFlow o en otros lugares.
// bad
var example = 42;
// good
const example = 42; se prefieren las funciones de flecha. Se prefieren las funciones. Proporciona una sintaxis concisa y evita algunos problemas relacionados con este apuntamiento. En comparación con la palabra clave de función, los desarrolladores deben dar prioridad al uso de funciones de flecha para declarar funciones, especialmente para declarar funciones anidadas.
Para ser honesto, una vez pensé que la función de las funciones de flecha era solo ser simple y hermosa. Pero ahora encuentro que tienen un papel más importante.
// malo
[1, 2, 3].map(función (x) {
const y = x 1;
return x * y;
});
// bueno
[1, 2, 3].map((x) =gt; {
const y = x 1;
return x * y
}); utilice cadenas de plantilla en lugar de cadenas de conexión al procesar plantillas de cadenas de varias líneas. Las cadenas funcionan mejor que las cadenas concatenadas complejas.
// bad
función sayHola(nombre) {
return '¿Cómo estás, 'nombre'?';
}
// bad
función sayHola(nombre) {
return ['¿Cómo estás, ', nombre, '?'].join();
}
// bad
función sayHola(nombre) {
return `¿Cómo estás, ${ nombre }?` ;
}
// bueno
función decirHola(nombre) {
return `¿Cómo estás, ${nombre}? `;
}No utilice caracteres de continuación de línea para dividir cadenas largas. En JS, \ también representa el carácter de continuación de línea. Los estándares de codificación de Google no permiten el uso de caracteres de continuación de línea ni en cadenas de plantilla ni en cadenas normales. Aunque esto está permitido en ES5, si \ va seguido de algún espacio en blanco de terminación, este comportamiento puede provocar errores que son difíciles de notar al revisar el código.
Esta regla es interesante, porque hay una regla diferente en las especificaciones de Airbnb
Google recomienda el siguiente método de redacción, mientras que Airbnb cree que se le debe permitir seguir su curso para casos especiales. procesamiento, puede ser tan largo como sea necesario.
// bad (recomendado para leer en PC)
const longString = 'Esta es una cadena muy larga que \
excede con creces el límite de 80 columnas. Desafortunadamente \
contiene largos espacios de espacios debido a la sangría de las \
líneas continuas.';
// bueno
const longString = 'Esta es una cadena muy larga que '
'excede con creces el límite de 80 columnas. No contiene '
'longitudes de espacios desde la ' < concatenada. /p>
'las cadenas están más limpias.'; Use for...of first En ES6, hay 3 bucles for diferentes. Aunque cada uno tiene sus escenarios de aplicación, Google todavía recomienda usar for...of.
Es realmente interesante que Google especifique un bucle for. Aunque esto sea extraño, no afecta mi aceptación de este punto de vista.
Solía pensar que for...in era adecuado para atravesar objetos, y for...of era adecuado para atravesar matrices. Porque me gusta esta forma de utilizar cada uno a su manera.
Aunque las especificaciones de Google entran en conflicto con este uso, todavía encuentro muy interesante la preferencia de Google por...de.
No utilice la instrucción eval a menos que esté en el cargador de código. De lo contrario, no utilice la estructura eval o Function(...string). Esta característica es potencialmente peligrosa y no funcionará en un entorno CSP.
Hay una sección en MDN que menciona específicamente no usar la declaración eval.
// malo
let obj = { a: 20, b: 30 };
let propName = getPropName() // devuelve "a" o "b"
eval( 'var resultado = obj.' propName );
// bueno
let obj = { a: 20, b: 30 };
let propName = getPropName(); // devuelve "a" o "b"
let result = obj[ propName ] // obj[ "a" ] es lo mismo que obj.a Convención de nomenclatura para constantes La nomenclatura de constantes debe estar en formato mayúscula y separada por guiones bajos
Si está seguro de que el valor de una variable no se modificará en el futuro, puede cambiar su nombre a Reescribir en modo todo en mayúsculas implica que se trata de una constante y no modifique su valor.
Una cosa a tener en cuenta al seguir esta regla es que si la constante es una función, debe usar la notación camelCase.
// malo
número constante = 5;
// bueno
NÚMERO constante = 5; time Cada declaración de variable debe corresponder a una sola variable. Declaraciones como let a = 1, b = 2 no deberían aparecer.
// malo
sea a = 1, b = 2, c = 3
// bueno
sea a =; 1;
let b = 2;
let c = 3; El uso de comillas simples solo permite el uso de comillas simples para envolver cadenas ordinarias y prohíbe el uso de comillas dobles. Si la cadena contiene comillas simples, se debe utilizar una cadena de plantilla.
// malo
let directiva = "Sin identificación de uno mismo o misión."
// malo
let diciendo = ' Di que no es así.';
// bueno
let directivo = 'No hay identificación de uno mismo ni de su misión.';
// bueno
let say = `Di que no es así`; Resumen Como dije al principio, no hay comandos en la especificación que deban aplicarse. Aunque Google es uno de los gigantes tecnológicos, esta especificación de código sólo se utiliza como referencia.
Google es una empresa de tecnología talentosa que contrata excelentes programadores para escribir código excelente. Es interesante ver las especificaciones del código publicadas por dicha empresa.
Si deseas implementar un código estilo Google, entonces puedes desarrollar estas especificaciones en el proyecto. Pero es posible que no esté de acuerdo con este código estándar y nadie le impedirá descartar algunas de sus reglas.
Personalmente creo que, en algunos escenarios, las especificaciones del código de Airbnb son mejores que las especificaciones del código de Google. Pero no importa cuál admita ni qué tipo de código escriba, lo más importante es cumplir siempre con la misma especificación de código en su mente.
Creo que domina el método después de leer el caso de este artículo. Para obtener más información interesante, preste atención a otros artículos relacionados en Gxl.com.
Lectura recomendada:
Introducción detallada al componente de registro predeterminado de Express, Morgan
Los pasos específicos de Vue para implementar la representación del lado del servidor basada en Nuxt.js