집 > 기사 > 웹 프론트엔드 > Google에서는 어떤 JS 코드 사양을 발표했나요?

Google에서는 어떤 JS 코드 사양을 발표했나요?

php中世界最好的语言원래의: 2018-04-08 09:54:591505검색

이번에는 구글에서 공개한 JS코드 스펙이 무엇인지, 구글에서 공개한 JS 코드 스펙을 사용할 때 주의사항에 대해 소개해드리려고 합니다. 실제 사례를 살펴보겠습니다.

Google에서 코딩 사양이 익숙하지 않은 분들을 위해 JS 코드 사양을 공개했습니다. 간결하고 이해하기 쉬운 코드를 작성하기 위한 모범 사례가 나열되어 있습니다.

코드 사양은 올바른

JavaScript 코드를 작성하기 위한 규칙이 아니라 소스 코드 작성 패턴을 일관되게 유지하기 위한 선택입니다. 이는 유연하고 덜 제한적이어서 개발자가 다양한 코딩 스타일을 사용할 수 있는 JavaScript 언어의 경우 특히 그렇습니다.

Google과 Airbnb는 각각 가장 인기 있는 코딩 표준의 절반을 차지합니다. JS 코드 작성에 오랜 시간을 투자할 예정이라면 두 회사의 코딩 표준을 꼭 읽어보시길 권합니다.

다음에 쓸 내용은 개인적으로 Google 코딩 표준의 일상적인 개발과 밀접하게 관련되어 있다고 생각하는 13가지 규칙입니다.

그들이 다루는 문제는 탭과 공백, 세미콜론 사용을 강제할지 여부 등 매우 논란의 여지가 많습니다. 또한 나를 놀라게 하고 종종 JS 코드 작성 습관을 바꾸게 만드는 몇 가지 규칙도 있습니다.

각 규칙에 대해 먼저 사양을 요약한 다음 사양에서 자세한 설명을 인용하겠습니다. 또한 이러한 규칙을 따르는 것의 중요성을 보여주기 위해 몇 가지 적절한 반례를 제시하겠습니다.

탭 대신 공백을 사용하세요

각 줄의 종결자 시퀀스 외에도 ASCII 가로 공백 문자(0x20)는 소스 파일의 어느 위치에나 나타날 수 있는 유일한 공백 문자입니다. 이는 탭 문자를 들여쓰기 제어에 사용해서는 안 된다는 의미이기도 합니다.

사양에는 들여쓰기가 4개가 아닌 2개의 스페이스 밴드를 사용하여 달성되어야 한다고 명시되어 있습니다.

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

세미콜론은 생략할 수 없습니다

모든 문장은 세미콜론으로 끝나야 합니다. 세미콜론을 자동으로 추가하는 JS 기능에 의존하는 것은 허용되지 않습니다.

누군가가 이 규칙에 반대하는 이유를 이해할 수는 없지만, 세미콜론 사용은 "공백 대 탭" 문제만큼 논란이 된 것 같습니다. 구글은 세미콜론은 필수이므로 생략할 수 없다고 밝혔습니다.

// 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 모듈의 의미가 아직 완전히 결정되지 않았으므로 내보내기 및 가져오기 키워드 등 당분간 사용하지 마세요. 사양이 확정되면 이 규칙을 무시하십시오.

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

번역자 주: 이 규칙을 따르는 것은 현실적이지 않다고 생각합니다. 결국 바벨은 이미 존재합니다. 그리고 React를 사용할 때 가장 좋은 방법은 ES6 모듈을 사용하는 것입니다.

코드 가로 정렬은 권장하지 않습니다

Google 코드 사양에서는 코드 가로 정렬을 허용하지만 권장하지는 않습니다. 이전 코드에서 수평 정렬을 수행했더라도 앞으로는 이러한 동작을 피해야 합니다.

코드를 가로로 정렬하면 코드에 공백이 추가되어 인접한 두 줄의 문자가 세로줄에 있는 것처럼 보입니다.

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

화살표 함수 사용을 선호하세요

화살표 함수는 간결한 구문을 제공하고 이 포인팅과 관련된 몇 가지 문제를 방지합니다. 함수 키워드와 비교할 때 개발자는

함수 선언, 특히 중첩된 함수를 선언할 때 화살표 함수를 사용하는 데 우선순위를 두어야 합니다.

솔직히 화살표 함수의 역할은 단순하고 아름답기만 하면 된다고 생각한 적이 있습니다. 하지만 이제 나는 그들이 더 중요한 역할을 갖고 있다는 것을 깨달았습니다.

// 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则认为应该顺其自然，不做特殊处理，该多长就多长。

// 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的代码规范要出色。但不管你支持哪一种，也不管你编写的是什么类型的代码，最重要的是在脑海中时刻遵守着同一份代码规范。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！