Heim >Web-Frontend >js-Tutorial >Was Sie über die von Google veröffentlichten JavaScript-Codespezifikationen wissen müssen
Die Codespezifikation ist keine Regel zum Schreiben von korrektem JavaScript-Code, sondern eine Entscheidung, um das Schreibmuster des Quellcodes konsistent zu halten. In diesem Artikel erfahren Sie, was Sie über die von Google veröffentlichten JavaScript-Codespezifikationen wissen müssen. Interessierte Freunde sollten einen Blick darauf werfen.
Google hat eine JS-Codespezifikation für diejenigen veröffentlicht, die mit den Codespezifikationen nicht vertraut sind . Es listet Best Practices zum Schreiben von prägnantem und verständlichem Code auf.
Die Codespezifikation ist keine Regel zum Schreiben von korrektem JavaScript-Code, sondern eine Entscheidung zur Aufrechterhaltung eines konsistenten Quellcode-Schreibmusters. Dies gilt insbesondere für die JavaScript-Sprache, da sie flexibel und weniger restriktiv ist und es Entwicklern ermöglicht, viele verschiedene Codierungsstile zu verwenden.
Google und Airbnb sind jeweils für die Hälfte der beliebtesten Codierungsstandards verantwortlich. Wenn Sie viel Zeit in das Schreiben von JS-Code investieren, empfehle ich Ihnen dringend, die Codierungsstandards dieser beiden Unternehmen durchzulesen.
Was ich als nächstes schreiben möchte, sind die dreizehn Regeln, die meiner Meinung nach eng mit der täglichen Entwicklung in den Codespezifikationen von Google zusammenhängen.
Die Themen, mit denen sie sich befassen, sind sehr kontrovers, einschließlich Tabulatoren und Leerzeichen, ob die Verwendung von Semikolons erzwungen werden soll usw. Es gibt auch einige Regeln, die mich überraschen und oft dazu führen, dass sich meine Gewohnheiten beim Schreiben von JS-Code ändern.
Für jede Regel gebe ich zunächst eine Zusammenfassung der Spezifikation und zitiere dann die detaillierte Beschreibung aus der Spezifikation. Ich werde auch einige geeignete Gegenbeispiele nennen, um zu veranschaulichen, wie wichtig es ist, diese Regeln zu befolgen.
Zusätzlich zur Abschlusssequenz für jede Zeile ist das horizontale ASCII-Leerzeichen (0x20) das einzige eines, das in der Quelle vorkommen kann. Ein Leerzeichen an einer beliebigen Stelle in der Datei. Dies bedeutet auch, dass das Tabulatorzeichen nicht verwendet werden sollte und zur Steuerung des Einzugs verwendet werden sollte.
Die Spezifikation besagt dann, dass die Einrückung mit 2 statt 4 Leerzeichen erreicht werden soll.
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
Jede Anweisung muss mit einem Semikolon enden. Es ist nicht zulässig, sich auf die Fähigkeit von JS zu verlassen, automatisch Semikolons hinzuzufügen.
Obwohl ich nicht verstehe, warum irgendjemand Einwände gegen diese Regel erheben sollte, ist die Verwendung von Semikolons offenbar ebenso umstritten wie die Frage „Leerzeichen vs. Tabulatoren“. Google sagte, dass das Semikolon notwendig ist und nicht weggelassen werden darf.
// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')
// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
jedi.father = 'vader';
});
Aufgrund der unvollständigen Semantik von ES6-Module sind in Ordnung, verwenden Sie daher vorerst keine Schlüsselwörter wie „Export“ und „Import“. Sobald die Spezifikationen festgelegt sind, ignorieren Sie diese Regel bitte.
// 暂时不要编写下面的代码：
//------ 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';
Anmerkung des Übersetzers: Ich halte es für unrealistisch, dieser Regel zu folgen, schließlich existiert Babel bereits. Und bei der Verwendung von React besteht die beste Vorgehensweise darin, ES6-Module zu verwenden.
Die Codierungsstandards von Google erlauben eine horizontale Ausrichtung des Codes, empfehlen diese jedoch nicht. Auch wenn im vorherigen Code eine horizontale Ausrichtung durchgeführt wurde, sollte dieses Verhalten in Zukunft vermieden werden.
Durch die horizontale Ausrichtung des Codes werden zusätzliche Leerzeichen zum Code hinzugefügt, sodass Zeichen in zwei benachbarten Zeilen so aussehen, als stünden sie auf einer vertikalen Linie.
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
Verwenden Sie const oder let, um alles lokal zu deklarieren Variablen. Wenn die Variable nicht neu zugewiesen werden muss, sollte standardmäßig const verwendet werden. Die Verwendung des Schlüsselworts var sollte abgelehnt werden.
Ich weiß nicht, ob es daran liegt, dass niemand sie überzeugen kann, oder ob es daran liegt, dass alte Gewohnheiten nur schwer aussterben. Derzeit sehe ich immer noch viele Leute, die var verwenden, um Variablen auf StackOverFlow oder anderswo zu deklarieren.
// bad var example = 42; // good const example = 42;
Pfeilfunktionen bieten eine prägnante Syntax und vermeiden einige Probleme mit diesem Hinweis. Im Vergleich zum Funktionsschlüsselwort sollten Entwickler der Verwendung von Pfeilfunktionen zum Deklarieren von Funktionen Vorrang einräumen, insbesondere zum Deklarieren verschachtelter Funktionen.
Um ehrlich zu sein, dachte ich einmal, dass die Rolle der Pfeilfunktionen nur darin besteht, einfach und schön zu sein. Aber jetzt finde ich, dass sie eine wichtigere Rolle spielen.
// 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;
});
Beim Umgang mit mehreren Leitungen Zeichenvorlagenzeichenfolgen sind leistungsfähiger als komplex verkettete Zeichenfolgen.
// 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}?`;
}
In JS , Stellt auch das Zeilenfortsetzungszeichen dar. Die Codierungsstandards von Google erlauben weder in Vorlagenzeichenfolgen noch in normalen Zeichenfolgen die Verwendung von Zeilenfortsetzungszeichen. Obwohl dies in ES5 zulässig ist, kann dieses Verhalten, wenn darauf ein schließendes Leerzeichen folgt, zu Fehlern führen, die bei der Überprüfung des Codes schwer zu erkennen sind.
Diese Regel ist interessant, weil es in den Spezifikationen von Airbnb eine andere Regel gibt
Google empfiehlt die folgende Schreibweise, während Airbnb der Meinung ist, dass es seinen Lauf nehmen darf und nichts Besonderes sein sollte done Verarbeiten Sie es so lange wie nötig.
// 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.';
在ES6中，有3种不同的for循环。尽管每一种有它的应用场景，但Google仍推荐使用for...of。
真有趣，Google居然会特别指定一种for循环。虽然这很奇怪，但不影响我接受这一观点。
以前我认为for...in适合遍历Object，而for...of适合遍历数组。因为我喜欢这种各司其职的使用方式。
尽管Google的规范与这种使用方式相冲突，但Google对for...of的偏爱依然让我觉得十分有趣。
除非是在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的代码规范要出色。但不管你支持哪一种，也不管你编写的是什么类型的代码，最重要的是在脑海中时刻遵守着同一份代码规范。
上面是我整理给大家的，希望今后会对大家有帮助。
相关文章：
浅析json与jsonp区别及通过ajax获得json数据后格式的转换
Das obige ist der detaillierte Inhalt vonWas Sie über die von Google veröffentlichten JavaScript-Codespezifikationen wissen müssen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!