Googleが公開したJavaScriptコード仕様について知っておくべきこと

コード仕様は、正しい JavaScript コードを記述するためのルールではなく、ソース コードの記述パターンの一貫性を保つための選択です。この記事では、Google が公開した JavaScript コードの仕様について知っておくべきことを紹介します。興味のある方はぜひ一緒にご覧ください

コードの仕様に詳しくない人のために、Google は JS コードの仕様を公開しました。簡潔でわかりやすいコードを記述するためのベスト プラクティスをリストします。

コード仕様は、正しい JavaScript コードを記述するためのルールではなく、ソース コードの記述パターンの一貫性を保つための選択です。これは、JavaScript 言語に特に当てはまります。JavaScript 言語は柔軟で制限が少ないため、開発者はさまざまなコーディング スタイルを使用できます。

Google と Airbnb はそれぞれ、最も人気のあるコーディング標準の半分を占めています。 JS コードの作成に長い時間を費やす場合は、これら 2 社のコーディング標準を一読することを強くお勧めします。

次に私が書こうとしているのは、Google のコーディング標準における日々の開発に密接に関連していると私が個人的に考える 13 のルールです。

タブとスペース、セミコロンの使用を強制するかどうかなど、彼らが扱っている問題は非常に物議を醸しています。また、私にとって驚くべきルールがいくつかあり、JS コードを書く習慣を変えることになることがよくあります。

各ルールについて、最初に仕様の概要を示し、次に詳細な説明を仕様から引用します。また、これらのルールに従うことの重要性を示すために、いくつかの適切な反例も示します。

タブの代わりにスペースを使用してください

各行のターミネータシーケンスに加えて、ASCII 水平スペース文字 (0x20) は、ソース ファイル内のどこにでも使用できる唯一のスペース文字です。これは、タブ文字を使用すべきではなく、インデントの制御に使用すべきであることも意味します。

仕様では、インデントは 4 つではなく 2 つのスペース バンドを使用して実現する必要があると記載されています。

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

セミコロンは省略できません

すべてのステートメントはセミコロンで終わる必要があります。 JS のセミコロンを自動的に追加する機能に依存することは許可されていません。

なぜこのルールに反対する人がいるのか理解できませんが、セミコロンの使用は「スペースとタブ」の問題と同じくらい物議を醸しているようです。 Googleによればセミコロンは必須で省略できないとのこと。

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

当面はES6モジュールを使用しないでください

ES6モジュールのセマンティクスがまだ完全に決定されていないため、当面はexportやimportなどのキーワードを使用しないでください。仕様が決定したら、このルールは無視してください。

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

訳者注: 結局のところ、babel はすでに存在しているので、このルールに従うのは現実的ではないように感じます。 React を使用する場合、ベスト プラクティスは ES6 モジュールを使用することです。

コードの水平方向の配置は推奨されません

Google のコード仕様では、コードの水平方向の配置は許可されていますが、推奨されていません。たとえ前のコードで水平方向の配置が行われていたとしても、今後はこの動作を避ける必要があります。

コードを水平方向に整列させると、コード内に余分なスペースが追加され、隣接する 2 行の文字が垂直線上に見えるようになります。

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

var

を削除して、すべてのローカル変数を宣言するにはconstまたはletを使用します。変数を再割り当てする必要がない場合は、デフォルトで const を使用する必要があります。キーワード var の使用は拒否される必要があります。

誰も彼らを説得できないからなのか、それとも古い習慣がなかなか消えないからなのかはわかりません。現在でも、StackOverFlow などで変数を宣言するために var を使用している人を多く見かけます。

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

アロー関数の使用を推奨します

アロー関数は簡潔な構文を提供し、このポインティングに関するいくつかの問題を回避します。 function キーワードと比較して、開発者はアロー関数を使用して関数を宣言すること、特にネストされた関数を宣言することを優先する必要があります。

正直に言うと、アロー関数の役割はシンプルで美しいことだけだと思っていたことがあります。しかし今では、彼らにはもっと重要な役割があることがわかりました。

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

接続文字列の代わりにテンプレート文字列を使用してください

複数行の文字列を扱う場合、テンプレート文字列は複雑に連結された文字列よりもパフォーマンスが高くなります。

// 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}?`;
}

長い文字列を分割するために行継続文字を使用しないでください

JSでは行継続文字も表します。 Google のコーディング標準では、テンプレート文字列でも通常の文字列でも行継続文字の使用は許可されていません。これは ES5 では許可されていますが、その後に終了空白が続くと、この動作によりコードをレビューするときに気づきにくいエラーが発生する可能性があります。

このルールは非常に興味深いです。なぜなら、Airbnbの仕様には別のルールがあるからです。

Googleは次のような書き方を推奨していますが、Airbnbは、特別な扱いをせずに自然に受け入れるべきであると考えており、次のとおりである必要があります。である必要があります。

りー

优先使用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数据后格式的转换

以上がGoogleが公開したJavaScriptコード仕様について知っておくべきことの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。