Ce que vous devez savoir sur les spécifications du code JavaScript publiées par Google

La spécification du code n'est pas une règle pour écrire du code JavaScript correct, mais un choix pour maintenir un modèle d'écriture de code source cohérent. Cet article vous présente ce que vous devez savoir sur les spécifications du code JavaScript publiées par Google. Les amis intéressés devraient y jeter un œil

Google a publié une spécification du code JS pour ceux qui ne sont pas familiers avec les spécifications du code. . Il répertorie les meilleures pratiques pour écrire du code concis et compréhensible.

La spécification du code n'est pas une règle pour écrire du code JavaScript correct, mais un choix pour maintenir un modèle d'écriture de code source cohérent. Cela est particulièrement vrai pour le langage JavaScript, car il est flexible et moins restrictif, permettant aux développeurs d'utiliser de nombreux styles de codage différents.

Google et Airbnb représentent chacun la moitié des normes de codage les plus populaires. Si vous envisagez d'investir beaucoup de temps dans l'écriture de code JS, je vous recommande fortement de lire les normes de codage de ces deux sociétés.

Ce que je vais écrire ensuite, ce sont les treize règles qui, selon moi personnellement, sont étroitement liées au développement quotidien des spécifications du code de Google.

Les questions qu'ils traitent sont très controversées, notamment les tabulations et les espaces, s'il faut forcer l'utilisation des points-virgules, etc. Il y a aussi certaines règles qui me surprennent et finissent souvent par changer mes habitudes d'écriture de code JS.

Pour chaque règle, je donnerai d'abord un résumé du cahier des charges puis citerai la description détaillée du cahier des charges. Je donnerai également quelques contre-exemples appropriés pour démontrer l’importance de suivre ces règles.

Utilisez des espaces au lieu des tabulations

En plus de la séquence de fin de chaque ligne, le caractère d'espace horizontal ASCII (0x20) est le seul celui qui peut apparaître dans la source Un caractère espace n'importe où dans le fichier. Cela signifie également que le caractère de tabulation ne doit pas être utilisé pour contrôler l'indentation.

La spécification indique ensuite que l'indentation doit être réalisée en utilisant 2 espaces au lieu de 4.

// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}

Le point-virgule ne peut pas être omis

Chaque instruction doit se terminer par un point-virgule La fin. S'appuyer sur la capacité de JS à ajouter automatiquement des points-virgules n'est pas autorisé.

Bien que je ne comprenne pas pourquoi quelqu'un s'opposerait à cette règle, l'utilisation des points-virgules est apparemment devenue aussi controversée que la question « espaces contre tabulations ». Google a déclaré que le point-virgule est nécessaire et ne peut être omis.

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

Ne pas encore utiliser le module ES6

Depuis la sémantique de Le module ES6 n'est pas encore entièrement sûr, alors n'utilisez pas de mots-clés tels que exporter et importer pour l'instant. Une fois leurs spécifications finalisées, veuillez ignorer cette règle.

// 暂时不要编写下面的代码：
//------ 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';

Note du traducteur : je pense qu'il n'est pas réaliste de suivre cette règle, après tout, Babel existe déjà. Et lorsque vous utilisez React, la meilleure pratique consiste à utiliser des modules ES6.

L'alignement horizontal du code n'est pas recommandé

Les normes de codage de Google autorisent mais ne recommandent pas l'alignement horizontal du code. Même si l'alignement horizontal était effectué dans le code précédent, ce comportement devrait être évité à l'avenir.

L'alignement horizontal du code ajoutera des espaces supplémentaires au code, donnant l'impression que les caractères sur deux lignes adjacentes sont sur une ligne verticale.

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

Éviter var

Utilisez const ou let pour déclarer toutes les variables locales . Si la variable n'a pas besoin d'être réaffectée, const doit être utilisée par défaut. L'utilisation du mot-clé var doit être rejetée.

Je ne sais pas si c’est parce que personne n’arrive à les convaincre, ou si c’est parce que les vieilles habitudes ont la vie dure. Actuellement, je vois encore de nombreuses personnes utiliser var pour déclarer des variables sur StackOverFlow ou ailleurs.

// bad
var example = 42;
// good
const example = 42;

Utilisez d'abord les fonctions fléchées

Les fonctions fléchées fournissent une syntaxe concise, et évite certains problèmes liés à ce pointage. Par rapport au mot-clé function, les développeurs devraient donner la priorité à l'utilisation de fonctions fléchées pour déclarer des fonctions, en particulier pour déclarer des fonctions imbriquées.

Pour être honnête, je pensais autrefois que le rôle des fonctions fléchées était uniquement d'être simple et beau. Mais maintenant, je trouve qu'ils ont un rôle plus important.

// 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;
});

Utilisez des chaînes de modèle au lieu de chaînes de connexion

Lorsque vous traitez plusieurs Lors de la construction de chaînes, les chaînes modèles fonctionnent mieux que les chaînes concaténées complexes.

// bad
function sayHi(name) {
 return 'How are you, ' + name + '?';
}
// bad
function sayHi(name) {
 return ['How are you, ', name, '?'].join();
}
// bad
function sayHi(name) {
 return `How are you, ${ name }?`;
}
// good
function sayHi(name) {
 return `How are you, ${name}?`;
}

N'utilisez pas de caractères de continuation de ligne pour diviser de longues chaînes

en JS, représente également le caractère de continuation de ligne. Les normes de codage de Google n'autorisent pas l'utilisation de caractères de continuation de ligne dans les chaînes de modèle ou dans les chaînes ordinaires. Bien que cela soit autorisé dans ES5, s'il est suivi d'un espace de fermeture, ce comportement peut conduire à des erreurs difficiles à remarquer lors de la révision du code.

Cette règle est intéressante car il y a une règle différente dans le cahier des charges d'Airbnb

Google recommande la manière d'écrire suivante, alors qu'Airbnb estime qu'il faut le laisser suivre son cours et que rien de spécial ne doit être done Traitez-le aussi longtemps que nécessaire.

// bad (建议在PC端阅读)
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.';
// good
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

在ES6中，有3种不同的for循环。尽管每一种有它的应用场景，但Google仍推荐使用for...of。

真有趣，Google居然会特别指定一种for循环。虽然这很奇怪，但不影响我接受这一观点。

以前我认为for...in适合遍历Object，而for...of适合遍历数组。因为我喜欢这种各司其职的使用方式。

尽管Google的规范与这种使用方式相冲突，但Google对for...of的偏爱依然让我觉得十分有趣。

不要使用eval语句

除非是在code loader中，否则不用使用eval或是Function(...string)结构。这个功能具有潜在的危险性，并且在CSP环境中无法起作用。

MDN中有一节专门提到不要使用eval语句。

// bad
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
eval( 'var result = obj.' + propName );
// good
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

常量的命名规范

常量命名应该使用全大写格式，并用下划线分割

如果你确定一定以及肯定一个变量值以后不会被修改，你可以将它的名称使用全大写模式改写，暗示这是一个常量，请不要修改它的值。

遵守这条规则时需要注意的一点是，如果这个常量是一个函数，那么应该使用驼峰式命名法。

// bad
const number = 5;
// good
const NUMBER = 5;

每次只声明一个变量

每一个变量声明都应该只对应着一个变量。不应该出现像let a = 1,b = 2;这样的语句。

// bad
let a = 1, b = 2, c = 3;
// good
let a = 1;
let b = 2;
let c = 3;

使用单引号

只允许使用单引号包裹普通字符串，禁止使用双引号。如果字符串中包含单引号字符，应该使用模板字符串。

// bad
let directive = "No identification of self or mission."
// bad
let saying = 'Say it ain\u0027t so.';
// good
let directive = 'No identification of self or mission.';
// good
let saying = `Say it ain't so`;

总结

就像我在开头所说那样，规范中没有需要强制执行的命令。尽管Google是科技巨头之一，但这份代码规范也仅仅是用来当作参考罢了。

Google是一家人才汇聚的科技公司，雇佣着出色的程序员来编写优秀的代码。能够看到这样的公司发布的代码规范是一件很有趣的事情。

如果你想要实现一种Google式的代码，那么你可以在项目中制定这些规范。但你可能并不赞成这份代码规范，这时也没有人会阻拦你舍弃其中某些规则。

我个人认为在某些场景下，Airbnb的代码规范比Google的代码规范要出色。但不管你支持哪一种，也不管你编写的是什么类型的代码，最重要的是在脑海中时刻遵守着同一份代码规范。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

Ajax发送和接收请求

ajax异步加载图片实例分析

浅析json与jsonp区别及通过ajax获得json数据后格式的转换

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!