References: 13 Noteworthy Points from Google’s JavaScript Style Guide
13 Noteworthy Points from Google’s JavaScript Style Guide
For anyone who isn’t already familiar with it, Google puts out a style guide for writing JavaScript that lays out (what Google believes to…
medium.freecodecamp.org
다음의 내용은 위의 글을 참조한 내용입니다.
1.Use spaces, not tabs - 탭 대신 스페이스를 사용하세요.
The ASCII horizontal space character (0x20) is the only whitespace character that appears anywhere in a source file.
- ASCII 수평 공백 문자 (0x20)는 소스 파일의 아무 곳에 나 나타나는 유일한 공백 문자입니다.
This implies that… Tab characters are not used for indentation.
- 탭 문자는 들여쓰기에 사용하지 않습니다.
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
2. Semicolons ARE required - 세미콜론은 필요합니다.
Every statement must be terminated with a semicolon.
-모든 문장은 세미콜론으로 끝나야 합니다.
Relying on automatic semicolon insertion is forbidden.
- 자동으로 세미콜론이 삽입되는것에 의존하는것은 금지되어있습니다.
왜 이 아이디어에 반대하는 사람이 있는지는 상상할 수 없습니다만, JS에서 세미콜론을 일관되게 사용하는것이 새로운 'Space 대 Tab' 논쟁이 되고 있습니다. 구글은 세미콜론을 지키기 위해 단호히 나왔습니다.
// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')
// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
jedi.father = 'vader';
});
3. Don’t use ES6 modules (yet) - (아직은) ES6 모듈을 사용하지 마세요.
Do not use ES6 modules yet (i.e. the export and import keywords), as their semantics are not yet finalized.
- 의미론이 아직 확정되지 않았으므로 ES6 모듈 (예를 들면 export와 import 키워드들)을 사용하지 마세요.
Note that this policy will be revisited once the semantics are fully-standard.
- 이 정책은 의미론이 완전히 표준화되면 다시 검토될 것입니다.
//이러한 것들을 아직 하지 마세요:
//------ 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';
4. Horizontal alignment is discouraged (but not forbidden) - 수평정렬은 권장되지 않습니다. (그러나 금지되지는 않습니다.)
This practice is permitted, but it is generally discouraged by Google Style.
- 이 방법은 허용이 됩니다만 일반적으로 구글 스타일에서는 권장되지 않습니다.
It is not even required to maintain horizontal alignment in places where it was already used.
- 이미 사용된 장소에서도 수평정렬을 유지할 필요가 없습니다.
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
5. Don’t use var anymore. - 더이상 var을 사용하지 마세요.
Declare all local variables with either const or let.
- 모든 로컬 변수들을 const나 let으로 선언하세요.
Use const by default, unless a variable needs to be reassigned.
- 변수에 재할당이 필요한 경우가 아니면 const를 기본으로 사용하세요.
The var keyword must not be used.
- var 키워드는 사용되지 말아야 합니다.
아직도 StackOverflow 및 다른곳에 있는 코드 샘플에서 var를 사용하는 사람이 보입니다. 누군가가 그로 인해 사건을 만들지, 단지 죽어가는 오래된 습관인지는 알 수 없습니다.
// bad
var example = 42;
// good
let example = 42;
6. Arrow functions are preferred - 화살표 함수가 선호됩니다.
Arrow functions provide a concise syntax and fix a number of difficulties with this.
- 화살표 함수는 간결한 구문을 제공하고 그로인해 많은 어려움을 해결합니다.
Prefer arrow functions over the function keyword, particularly for nested functions.
- 특히 중첩된 함수의 경우 화살표 함수가 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;
});
7. Use template strings instead of concatenation - 연결하는것 대신에 탬플릿 문자열을 사용하세요.
Use template strings (delimited with `) over complex string concatenation, particularly if multiple string literals re involved.
- 여러 string 리터럴이 관련되어있는 경우 특히 복잡한 문자열 연결에 대해서 템플릿 문자열 (`로 구분됨)을 사용하세요.
Template strings may span multiple lines.
- 템플릿 문자열은 여러 줄에 걸쳐있을 수도 있습니다.
// 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}?`;
}
8. Don’t use line continuations for long strings - 긴 문자열에서 줄 연속을 쓰지 마세요.
Do not use line continuations (that is, ending a line inside a string literal with a backslash) in either ordinary or emplate string literals.
- 일반적이거나 템플릿 문자열의 리터럴에서 줄 연속 (문자열 리터럴 내에서 백 슬래시로 줄을 끝내는것)을 사용하지 마세요.
Even though ES5 allows this, it can lead to tricky errors if any trailing whitespace comes after the slash, and is less obvious to readers.
- ES5에서는 이것을 허용하지만 슬래시 뒤에 오는 공백이 있으면 보는이가 쉽게 알 수 없으므로 까다로운 오류가 발생할 수 있습니다.
흥미롭게도 이것은 Google과 Airbnb가 동의하지 않는 규칙입니다 (Airbnb의 스펙 참조).
Google은 긴 문자열 (아래 그림 참조)을 연결하는 것을 권장하지만 Airbnb의 스타일 가이드는 본질적으로 아무 것도하지 말고 긴 문자열을 필요하면 길게 사용할 수 있도록 권장합니다.
// bad (미안하지만 모바일에선 잘 표시되지 않습니다.)
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.';
9. “for… of” is the preferred type of ‘for loop’ - "for ... of"는 'for loop'의 바람직한 유형입니다.
With ES6, the language now has three different kinds of for loops.
- ES6에서는 이제 언어에 3 가지 다른 종류의 for loop를 갖습니다.
All may be used, though for-of loops should be preferred when possible.
내게 묻는다면 이상한 것이지만, 난 구글이 for루프의 바람직한 유형을 선헌한것이 꽤나 흥미롭기 때문에 이것을 포함시킬 것이라고 생각했습니다.
저는 항상 "... in" 루프는 객체에 더 좋았고, "for ... of"는 배열에 더 적합하다는 생각 이었습니다. - "올바른 작업을 위한 올바른 도구"유형의 상황.
구글의 사향이 반드시 그 생각과 상반되는것은 아니지만, 특히 이 루프에 대한 선호가 있단것을 하는것은 여전히 흥미롭습니다.
10. Don’t use eval() - eval()을 사용하지 마세요
Do not use eval or the Function(...string) constructor (except for code loaders).
- eval 또는 Function (... string) 생성자를 사용하지 마세요 (코드 로더는 제외됩니다).
These features are potentially dangerous and simply do not work in CSP environments.
eval()의 MDN 페이지에는 "Do not ever use 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
11. Constants should be named in ALL_UPPERCASE separated by underscores - 상수는 밑줄로 구분된 대문자로 명명되어야 합니다.
Constant names use CONSTANT_CASE: all uppercase letters, with words separated by underscores.
변수가 변경되지 않아야한다고 절대적으로 확신하는 경우 상수의 이름을 대문자로 표시하여 이를 나타낼 수 있습니다. 이렇게하면 코드 전체에서 사용됨에 따라 상수의 불변성이 명확해집니다.
이 규칙의 주목할만한 예외는 상수가 function-scope인 경우입니다. 이 경우 camelCase로 작성해야합니다.
// bad
const number = 5;
// good
const NUMBER = 5;
12. One variable per declaration - 선언 하나에 변수 하나
Every local variable declaration declares only one variable: declarations such as let a = 1, b = 2; are not used.
- 모든 지역 변수의 선언은 하나의 변수만 선언합니다: let a = 1, b = 2;와 같은 선언은 사용하지 않습니다.
// bad
let a = 1, b = 2, c = 3;
// good
let a = 1;
let b = 2;
let c = 3;
13. Use single quotes, not double quotes - 큰따옴표(") 대신 작은따옴표(')를 사용하세요.
Ordinary string literals are delimited with single quotes ('), rather than double quotes (").
- 일반적인 문자열 리터럴은 큰 따옴표(") 대신 작은 따옴표(')로 구분됩니다.
Tip: if a string contains a single quote character, consider using a template string to avoid having to escape the quote.
// 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 compliant source code’에 대한 가이드 라인을 따르고 싶다면 이러한 규칙들을 따라야 합니다.
물론 많은 사람들이 동의하지 않으며 이 중 일부 또는 전부를 마음대로 쓸 수 있습니다.
저는 개인적으로 Airbnb의 사양이 Google보다 더 매력적이라고 생각합니다.
이러한 특정 규칙을 취하는 태도에 상관없이 모든 종류의 코드를 작성할 때 문체의 일관성을 염두에 두는 것이 중요합니다.
'Programming > JavaScript' 카테고리의 다른 글
| [jqGrid] 컬럼 순서 변경시 오류가 날 경우 (0) | 2019.08.23 |
|---|---|
| 바벨(Babel)과 타입스크립트(Typescript)중 어떤걸 사용해야 할까 (0) | 2019.07.16 |
| NodeJS - Webpack 소개 (0) | 2019.04.15 |
| NodeJS - Meteor with React Tutorial (5) (0) | 2019.02.19 |
| NodeJS - Meteor with React Tutorial (4) (0) | 2019.02.19 |
