원문: https://github.com/airbnb/javascript
대체로 합리적인 JavaScript 접근 방법
Note: this guide assumes you are using Babel, and requires that you use babel-preset-airbnb or the equivalent. It also assumes you are installing shims/polyfills in your app, with airbnb-browser-shims or the equivalent.
참고: 이 가이드는 사용자가 Babel과 babel-preset-airbnb 또는 이와 동등한 것을 사용한다고 가정합니다. 또한 사용자가 어플리케이션에 airbnb-browser-shims와 함께 shims/polyfills 또는 이와 동등한 것을 설치했다고 가정합니다.
이 스타일 가이드는 다른 언어로도 제공됩니다. Translation을 보세요.
다른 스타일 가이드
- 형 (Types)
- 참조 (References)
- 객체 (Objects
- 배열 (Arrays)
- 비구조화 Destructuring
- 문자열 (Strings)
- 함수 (Functions)
- 화살표 함수 (Arrow Functions)
- 클래스 & 생성자 (Classes & Constructors)
- 모듈 (Modules)
- 이터레이터와 제너레이터 (Iterators and Generators)
- 속성 (Properties)
- 변수 (Variables)
- 호이스팅 (Hoisting)
- 비교 연산자 (Comparison Operators & Equality)
- 블록 (Blocks)
- 제어문 (Control Statements)
- 주석 (Comments)
- 공백 (Whitespace)
- 쉼표 (Commas)
- 세미콜론 (Semicolons)
- 형변환과 강제 (Type Casting & Coercion)
- 명명규칙 (Naming Conventions)
- 접근자 (Accessors)
- 이벤트 (Events)
- 제이쿼리 (jQuery)
- ES5 호환성 (ECMAScript 5 Compatibility)
- ES6+ 스타일 (ECMAScript 6+ (ES 2015+) Styles)
- 표준 라이브러리 (Standard Library)
- 테스트 (Testing)
- 성능 (Performance)
- 자료 (Resources)
- In the Wild
- Translation
- The JavaScript Style Guide Guide
- Chat With Us About JavaScript
- Contributors
- License
- Amendments
-
1.1 Primitives: When you access a primitive type you work directly on its value.
-
1.1 원시형: 원시형에 접근하면 값을 직접 조작하게 됩니다.
string
number
boolean
null
undefined
symbol
const foo = 1; let bar = foo; bar = 9; console.log(foo, bar); // => 1, 9
- Symbols cannot be faithfully polyfilled, so they should not be used when targeting browsers/environments that don't support them natively.
- symbol은 완전히 폴리필되지 않으므로, 이를 지원하지 않는 브라우저/환경을 대상으로 사용해서는 안 됩니다.
-
1.2 Complex: When you access a complex type you work on a reference to its value.
-
1.2 참조형: 참조형에 접근하면 참조를 통해 값을 조작하게 됩니다.
object
array
function
const foo = [1, 2]; const bar = foo; bar[0] = 9; console.log(foo[0], bar[0]); // => 9, 9
-
2.1 Use
const
for all of your references; avoid usingvar
. eslint:prefer-const
,no-const-assign
-
2.1 모든 참조에는
var
대신const
를 사용하세요. eslint:prefer-const
,no-const-assign
Why? This ensures that you can’t reassign your references, which can lead to bugs and difficult to comprehend code.
왜? 참조를 재할당 할 수 없게 함으로써, 이해하기 어려운 동시에 버그로 이어지는 코드를 방지합니다.
// bad var a = 1; var b = 2; // good const a = 1; const b = 2;
-
2.2 If you must reassign references, use
let
instead ofvar
. eslint:no-var
-
2.2 만약 참조를 재할당 해야 한다면
var
대신let
을 사용하세요. eslint:no-var
Why?
let
is block-scoped rather than function-scoped likevar
.왜?
var
처럼 함수스코프를 취하는 것 보다는 블록스코프를 취하는let
이 더 낫습니다.// bad var count = 1; if (true) { count += 1; } // good, use the let. let count = 1; if (true) { count += 1; }
-
2.3 Note that both
let
andconst
are block-scoped. -
2.3
let
과const
는 둘 다 블록스코프라는 것을 유의하세요.// const and let only exist in the blocks they are defined in. // const와 let은 선언된 블록 안에서만 존재합니다. { let a = 1; const b = 1; } console.log(a); // ReferenceError console.log(b); // ReferenceError
-
3.1 Use the literal syntax for object creation. eslint:
no-new-object
-
3.1 객체를 생성할 때는 리터럴 구문을 사용하세요. eslint:
no-new-object
// bad const item = new Object(); // good const item = {};
-
3.2 Use computed property names when creating objects with dynamic property names.
-
3.2 속성 계산명을 갖는 객체를 생성할 때는 속성 계산명을 사용하세요.
Why? They allow you to define all the properties of an object in one place.
왜? 이렇게 하면 객체의 모든 속성을 한 곳에서 정의할 수 있습니다.
function getKey(k) { return `a key named ${k}`; } // bad const obj = { id: 5, name: 'San Francisco', }; obj[getKey('enabled')] = true; // good const obj = { id: 5, name: 'San Francisco', [getKey('enabled')]: true, };
-
3.3 Use object method shorthand. eslint:
object-shorthand
-
3.3 메소드의 단축구문을 사용하세요. eslint:
object-shorthand
// bad const atom = { value: 1, addValue: function (value) { return atom.value + value; }, }; // good const atom = { value: 1, addValue(value) { return atom.value + value; }, };
-
3.4 Use property value shorthand. eslint:
object-shorthand
-
3.4 속성의 단축구문을 사용하세요. eslint:
object-shorthand
Why? It is shorter to write and descriptive.
왜? 설명이 간결해지기 때문입니다.
const lukeSkywalker = 'Luke Skywalker'; // bad const obj = { lukeSkywalker: lukeSkywalker, }; // good const obj = { lukeSkywalker, };
-
3.5 Group your shorthand properties at the beginning of your object declaration.
-
3.5 속성의 단축구문은 객체 선언의 시작 부분에 그룹화 해주세요.
Why? It’s easier to tell which properties are using the shorthand.
왜? 어떤 속성이 단축구문을 사용하고 있는지 알기 쉽게 해주기 때문입니다.
const anakinSkywalker = 'Anakin Skywalker'; const lukeSkywalker = 'Luke Skywalker'; // bad const obj = { episodeOne: 1, twoJediWalkIntoACantina: 2, lukeSkywalker, episodeThree: 3, mayTheFourth: 4, anakinSkywalker, }; // good const obj = { lukeSkywalker, anakinSkywalker, episodeOne: 1, twoJediWalkIntoACantina: 2, episodeThree: 3, mayTheFourth: 4, };
-
3.6 Only quote properties that are invalid identifiers. eslint:
quote-props
-
3.6 유효하지 않은 식별자에만 따옴표 속성을 사용하세요. eslint:
quote-props
Why? In general we consider it subjectively easier to read. It improves syntax highlighting, and is also more easily optimized by many JS engines.
왜? 일반적으로 이렇게 하는 것이 더 읽기 쉽습니다. 이렇게 하면 구문 강조를 개선하고, 많은 자바스크립트 엔진으로 하여금 더 쉽게 최적화 하도록 할 수 있습니다.
// bad const bad = { 'foo': 3, 'bar': 4, 'data-blah': 5, }; // good const good = { foo: 3, bar: 4, 'data-blah': 5, };
- 3.7 Do not call
Object.prototype
methods directly, such ashasOwnProperty
,propertyIsEnumerable
, andisPrototypeOf
.
-
3.7
hasOwnProperty
,propertyIsEnumerable
,isPrototypeOf
와 같은Object.prototype
메소드를 직접 호출하지 마세요.Why? These methods may be shadowed by properties on the object in question - consider
{ hasOwnProperty: false }
- or, the object may be a null object (Object.create(null)
).왜? 이러한 메소드들은 객체의 속성에 의해 가려질 수 있습니다. -
{ hasOwnProperty: false }
- 또는, 객체가 null 객체(Object.create(null)
)일 수도 있습니다.// bad console.log(object.hasOwnProperty(key)); // good console.log(Object.prototype.hasOwnProperty.call(object, key)); // best const has = Object.prototype.hasOwnProperty; // cache the lookup once, in module scope. /* or */ import has from 'has'; // https://www.npmjs.com/package/has // ... console.log(has.call(object, key));
-
3.8 Prefer the object spread operator over
Object.assign
to shallow-copy objects. Use the object rest operator to get a new object with certain properties omitted. -
3.8 객체에 대해 얕은 복사를 할 때는
Object.assign
대신 객체 전개 연산자를 사용하세요. 특정 속성이 생략된 새로운 개체를 가져올 때는 객체 나머지 연산자(object rest operator)를 사용하세요.// very bad const original = { a: 1, b: 2 }; const copy = Object.assign(original, { c: 3 }); // this mutates `original` ಠ_ಠ delete copy.a; // so does this // bad const original = { a: 1, b: 2 }; const copy = Object.assign({}, original, { c: 3 }); // copy => { a: 1, b: 2, c: 3 } // good const original = { a: 1, b: 2 }; const copy = { ...original, c: 3 }; // copy => { a: 1, b: 2, c: 3 } const { a, ...noA } = copy; // noA => { b: 2, c: 3 }
-
4.1 Use the literal syntax for array creation. eslint:
no-array-constructor
-
4.1 배열을 생성할 때 리터럴 구문을 사용하세요. eslint:
no-array-constructor
// bad const items = new Array(); // good const items = [];
-
4.2 Use Array#push instead of direct assignment to add items to an array.
-
4.2 배열에 직접 값을 할당하지 말고 Array#push를 사용하세요.
const someStack = []; // bad someStack[someStack.length] = 'abracadabra'; // good someStack.push('abracadabra');
-
4.3 Use array spreads
...
to copy arrays. -
4.3 배열을 복사할 때는 배열 전개 연산자
...
를 사용하세요.// bad const len = items.length; const itemsCopy = []; let i; for (i = 0; i < len; i += 1) { itemsCopy[i] = items[i]; } // good const itemsCopy = [...items];
-
4.4 To convert an iterable object to an array, use spreads
...
instead ofArray.from
. -
4.4 이터레이트 가능한 객체를 배열로 변환할 때는
Array.from
대신 전개 연산자...
를 사용하세요.const foo = document.querySelectorAll('.foo'); // good const nodes = Array.from(foo); // best const nodes = [...foo];
-
4.5 Use
Array.from
for converting an array-like object to an array. -
4.5 array-like 객체를 배열로 변환할 때는
Array.from
을 사용하세요.const arrLike = { 0: 'foo', 1: 'bar', 2: 'baz', length: 3 }; // bad const arr = Array.prototype.slice.call(arrLike); // good const arr = Array.from(arrLike);
-
4.6 Use Array.from instead of spread
...
for mapping over iterables, because it avoids creating an intermediate array. -
4.6 매핑할 때는 전개 연산자
...
대신Array.from
을 사용하세요. 중간 배열 생성을 방지하기 때문입니다.// bad const baz = [...foo].map(bar); // good const baz = Array.from(foo, bar);
-
4.7 Use return statements in array method callbacks. It’s ok to omit the return if the function body consists of a single statement returning an expression without side effects, following 8.2. eslint:
array-callback-return
-
4.7 배열 메소드 콜백에는 리턴 구문을 사용하세요. 만약 함수가 8.2와 같이 부작용 없는 단일 표현식을 반환하는 구문으로 구성되어 있다면 리턴 구문을 생략해도 됩니다. eslint:
array-callback-return
// good [1, 2, 3].map((x) => { const y = x + 1; return x * y; }); // good [1, 2, 3].map(x => x + 1); // bad - no returned value means `acc` becomes undefined after the first iteration [[0, 1], [2, 3], [4, 5]].reduce((acc, item, index) => { const flatten = acc.concat(item); acc[index] = flatten; }); // good [[0, 1], [2, 3], [4, 5]].reduce((acc, item, index) => { const flatten = acc.concat(item); acc[index] = flatten; return flatten; }); // bad inbox.filter((msg) => { const { subject, author } = msg; if (subject === 'Mockingbird') { return author === 'Harper Lee'; } else { return false; } }); // good inbox.filter((msg) => { const { subject, author } = msg; if (subject === 'Mockingbird') { return author === 'Harper Lee'; } return false; });
-
4.8 Use line breaks after open and before close array brackets if an array has multiple lines
-
4.8 배열이 여러 줄에 걸쳐 있다면 배열을 연 이후와 닫기 이전에 줄바꿈을 해주세요.
// bad const arr = [ [0, 1], [2, 3], [4, 5], ]; const objectInArray = [{ id: 1, }, { id: 2, }]; const numberInArray = [ 1, 2, ]; // good const arr = [[0, 1], [2, 3], [4, 5]]; const objectInArray = [ { id: 1, }, { id: 2, }, ]; const numberInArray = [ 1, 2, ];
-
5.1 Use object destructuring when accessing and using multiple properties of an object. eslint:
prefer-destructuring
-
5.1 하나의 객체에서 여러 속성에 접근할 때는 객체 비구조화를 사용하세요. eslint:
prefer-destructuring
Why? Destructuring saves you from creating temporary references for those properties.
왜? 비구조화는 속성들을 위한 임시적인 참조를 만들지 않도록 해줍니다.
// bad function getFullName(user) { const firstName = user.firstName; const lastName = user.lastName; return `${firstName} ${lastName}`; } // good function getFullName(user) { const { firstName, lastName } = user; return `${firstName} ${lastName}`; } // best function getFullName({ firstName, lastName }) { return `${firstName} ${lastName}`; }
-
5.2 Use array destructuring. eslint:
prefer-destructuring
-
5.2 배열 비구조화를 사용하세요. eslint:
prefer-destructuring
const arr = [1, 2, 3, 4]; // bad const first = arr[0]; const second = arr[1]; // good const [first, second] = arr;
-
5.3 Use object destructuring for multiple return values, not array destructuring.
-
5.3 여러 값을 반환하는 경우 배열 비구조화가 아닌 객체 비구조화를 사용하세요.
Why? You can add new properties over time or change the order of things without breaking call sites.
왜? 이렇게 하면 이후 호출처에 영향을 주지 않고 새로운 속성을 추가하거나 순서를 변경할 수 있습니다.
// bad function processInput(input) { // then a miracle occurs // 그리고 기적이 일어납니다 return [left, right, top, bottom]; } // the caller needs to think about the order of return data // 호출처에서 반환된 데이터의 순서를 고려할 필요가 있습니다 const [left, __, top] = processInput(input); // good function processInput(input) { // then a miracle occurs // 그리고 기적이 일어납니다 return { left, right, top, bottom }; } // the caller selects only the data they need // 호출처에서는 필요한 데이터만 선택하면 됩니다 const { left, top } = processInput(input);
-
6.1 문자열에는 작은 따옴표
''
를 사용하세요. eslint:quotes
// bad const name = "Capt. Janeway"; // bad - template literals should contain interpolation or newlines const name = `Capt. Janeway`; // good const name = 'Capt. Janeway';
-
6.2 Strings that cause the line to go over 100 characters should not be written across multiple lines using string concatenation.
-
6.2 100자가 넘는 문자열을 문자열 연결을 이용해 여러 줄에 걸쳐 쓰지 마세요.
Why? Broken strings are painful to work with and make code less searchable.
왜? 문자열이 끊어지면 작업하기 어렵고, 코드를 찾기 어렵게 됩니다.
// bad const errorMessage = 'This is a super long error that was thrown because \ of Batman. When you stop to think about how Batman had anything to do \ with this, you would get nowhere \ fast.'; // bad const errorMessage = 'This is a super long error that was thrown because ' + 'of Batman. When you stop to think about how Batman had anything to do ' + 'with this, you would get nowhere fast.'; // good const errorMessage = 'This is a super long error that was thrown because of Batman. When you stop to think about how Batman had anything to do with this, you would get nowhere fast.';
-
6.3 When programmatically building up strings, use template strings instead of concatenation. eslint:
prefer-template
template-curly-spacing
-
6.3 프로그램에서 문자열을 생성하는 경우, 문자열 연결 대신 템플릿 문자열을 사용하세요. eslint:
prefer-template
template-curly-spacing
Why? Template strings give you a readable, concise syntax with proper newlines and string interpolation features.
왜? 템플릿 문자열은 덧붙이기 기능과 적절한 줄바꿈 기능을 제공하는 간결한 문법으로, 가독성을 높여주기 때문입니다.
// 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}?`; }
- 6.4 Never use
eval()
on a string, it opens too many vulnerabilities. eslint:no-eval
- 6.4 절대로 문자열에
eval()
을 사용하지 마세요. 이는 너무나도 많은 취약점을 만듭니다. eslint:no-eval
-
6.5 Do not unnecessarily escape characters in strings. eslint:
no-useless-escape
-
6.5 문자열에 불필요한 이스케이프 문자를 사용하지 마세요. eslint:
no-useless-escape
Why? Backslashes harm readability, thus they should only be present when necessary.
왜? 백슬래시는 가독성을 해치기 때문에 필요할 때만 사용되어야 합니다.
// bad const foo = '\'this\' \i\s \"quoted\"'; // good const foo = '\'this\' is "quoted"'; const foo = `my name is '${name}'`;
-
7.1 Use named function expressions instead of function declarations. eslint:
func-style
-
7.1 함수선언식 대신 이름있는 함수표현식을 사용하세요. eslint:
func-style
Why? Function declarations are hoisted, which means that it’s easy - too easy - to reference the function before it is defined in the file. This harms readability and maintainability. If you find that a function’s definition is large or complex enough that it is interfering with understanding the rest of the file, then perhaps it’s time to extract it to its own module! Don’t forget to explicitly name the expression, regardless of whether or not the name is inferred from the containing variable (which is often the case in modern browsers or when using compilers such as Babel). This eliminates any assumptions made about the Error's call stack. (Discussion)
왜? 함수선언은 호이스트됩니다. 즉, 파일에서 함수를 정의하기 전에 함수를 참조하는 것이 쉽다는 것-너무 쉽다는 것-을 의미합니다. 이것은 가독성과 유지관리성를 해칩니다. 만약 함수의 정의가 나머지 파일을 이해하는데 방해가 될 정도로 크거나 복잡하다는 것을 발견한다면, 이제 함수를 모듈 밖으로 추출해내야 할 때라는 의미입니다! 포함된 변수로부터 추론된 이름인지와 관계 없이(현대 브라우저 또는 Babel과 같은 컴파일러를 쓸 때 흔히 볼 수 있듯이) 표현의 이름을 명시적으로 짓는 것을 잊지 마세요. 이를 통해 Error 콜 스택에 대한 모든 추정을 제거할 수 있습니다. (토론)
// bad function foo() { // ... } // bad const foo = function () { // ... }; // good // lexical name distinguished from the variable-referenced invocation(s) const short = function longUniqueMoreDescriptiveLexicalFoo() { // ... };
-
7.2 Wrap immediately invoked function expressions in parentheses. eslint:
wrap-iife
-
7.2 즉시 호출 함수 표현식을 괄호로 감싸세요. eslint:
wrap-iife
Why? An immediately invoked function expression is a single unit - wrapping both it, and its invocation parens, in parens, cleanly expresses this. Note that in a world with modules everywhere, you almost never need an IIFE.
왜? 즉시 호출 함수 표현식은 하나의 단위이며, 괄호로 이것을 감싸면 괄호 안의 표현을 명확하게 해주기 때문입니다. 모듈을 어디에서나 사용한다면 즉시 호출 표현식은 전혀 필요하지 않다는 점을 주의하세요.
// immediately-invoked function expression (IIFE) // 즉시 호출 함수 표현식 (IIFE) (function () { console.log('Welcome to the Internet. Please follow me.'); }());
- 7.3 Never declare a function in a non-function block (
if
,while
, etc). Assign the function to a variable instead. Browsers will allow you to do it, but they all interpret it differently, which is bad news bears. eslint:no-loop-func
- 7.3 함수 이외의 불록(
if
,while
, 등)에서 함수를 선언하지 마세요. 브라우저는 이를 허용하겠지만, 모두 다르게 해석합니다. eslint:no-loop-func
-
7.4 Note: ECMA-262 defines a
block
as a list of statements. A function declaration is not a statement. -
7.4 참고: ECMA-262 사양은
block
을 구문의 일람으로 정의하고 있지만 함수선언은 구문이 아닙니다.// bad if (currentUser) { function test() { console.log('Nope.'); } } // good let test; if (currentUser) { test = () => { console.log('Yup.'); }; }
-
7.5 Never name a parameter
arguments
. This will take precedence over thearguments
object that is given to every function scope. -
7.5 절대 매개변수 이름을
arguments
라고 짓지 마세요. 이것은 함수 스코프에 전해지는arguments
객체의 참조를 덮어써 버립니다.// bad function foo(name, options, arguments) { // ... } // good function foo(name, options, args) { // ... }
-
7.6 Never use
arguments
, opt to use rest syntax...
instead. eslint:prefer-rest-params
-
7.6 절대
arguments
를 사용하지마세요. 대신 나머지 문법(rest syntax)...
를 사용하세요. eslint:prefer-rest-params
Why?
...
is explicit about which arguments you want pulled. Plus, rest arguments are a real Array, and not merely Array-like likearguments
.왜?
...
을 사용하면 몇 개의 매개변수를 이용하고 싶은지를 확실히 할 수 있습니다. 더 나아가, 나머지 매개변수(rest arguments)는arguments
와 같은 Array-like 객체가 아닌 진짜 Array입니다.// bad function concatenateAll() { const args = Array.prototype.slice.call(arguments); return args.join(''); } // good function concatenateAll(...args) { return args.join(''); }
-
7.7 Use default parameter syntax rather than mutating function arguments.
-
7.7 함수의 매개변수를 바꾸기 보다는 기본 매개변수 문법을 사용하세요.
// really bad function handleThings(opts) { // No! We shouldn’t mutate function arguments. // Double bad: if opts is falsy it'll be set to an object which may // be what you want but it can introduce subtle bugs. opts = opts || {}; // ... } // still bad function handleThings(opts) { if (opts === void 0) { opts = {}; } // ... } // good function handleThings(opts = {}) { // ... }
-
7.8 Avoid side effects with default parameters.
-
7.8 부작용이 있을 기본 매개변수는 사용하지 마세요.
Why? They are confusing to reason about.
왜? 혼란을 야기하기 때문입니다.
var b = 1; // bad function count(a = b++) { console.log(a); } count(); // 1 count(); // 2 count(3); // 3 count(); // 3
-
7.9 Always put default parameters last.
-
7.9 기본 매개변수는 항상 뒤쪽에 두세요.
// bad function handleThings(opts = {}, name) { // ... } // good function handleThings(name, opts = {}) { // ... }
-
7.10 Never use the Function constructor to create a new function. eslint:
no-new-func
-
7.10 절대로 새로운 함수를 만들기 위해 함수 생성자를 사용하지 마세요. eslint:
no-new-func
Why? Creating a function in this way evaluates a string similarly to eval(), which opens vulnerabilities.
왜? 이러한 방법으로 문자열을 평가해 함수를 만드는 것은 eval()과 같은 수준의 취약점을 만듭니다.
// bad var add = new Function('a', 'b', 'return a + b'); // still bad var subtract = Function('a', 'b', 'return a - b');
-
7.11 Spacing in a function signature. eslint:
space-before-function-paren
space-before-blocks
-
7.11 함수 시그니처에 공백을 넣으세요. eslint:
space-before-function-paren
space-before-blocks
Why? Consistency is good, and you shouldn’t have to add or remove a space when adding or removing a name.
왜? 일관성을 갖는 것은 좋으니까요. 그리고 이렇게 하면 이름을 추가하거나 지울 때 공백을 건드릴 필요가 없게 됩니다.
// bad const f = function(){}; const g = function (){}; const h = function() {}; // good const x = function () {}; const y = function a() {};
-
7.12 Never mutate parameters. eslint:
no-param-reassign
-
7.12 절대로 매개변수를 바꾸지 마세요. eslint:
no-param-reassign
Why? Manipulating objects passed in as parameters can cause unwanted variable side effects in the original caller.
왜? 매개변수로 전달된 객체를 조작하면 원래 호출처에서 원치 않는 부작용을 일으킬 수 있습니다.
// bad function f1(obj) { obj.key = 1; } // good function f2(obj) { const key = Object.prototype.hasOwnProperty.call(obj, 'key') ? obj.key : 1; }
-
7.13 Never reassign parameters. eslint:
no-param-reassign
-
7.13 절대로 매개변수를 재할당하지 마세요. eslint:
no-param-reassign
Why? Reassigning parameters can lead to unexpected behavior, especially when accessing the
arguments
object. It can also cause optimization issues, especially in V8.왜? 매개변수를 재할당하는 것은 예측할 수 없는 결과를 불러 일으킵니다. 특히
arguments
객체에 접근할 때 말이죠. 또한 V8에서 최적화 문제를 일으킬 수도 있습니다.// bad function f1(a) { a = 1; // ... } function f2(a) { if (!a) { a = 1; } // ... } // good function f3(a) { const b = a || 1; // ... } function f4(a = 1) { // ... }
-
7.14 Prefer the use of the spread operator
...
to call variadic functions. eslint:prefer-spread
-
7.14 가변 인자 함수를 호출할 때는 전개 연산자
...
을 사용하세요. eslint:prefer-spread
Why? It’s cleaner, you don’t need to supply a context, and you can not easily compose
new
withapply
.왜? 이게 더 깔끔하니까요. 컨텍스트를 제공할 필요도 없고,
apply
로new
를 쉽게 구성할 수도 없습니다.// bad const x = [1, 2, 3, 4, 5]; console.log.apply(console, x); // good const x = [1, 2, 3, 4, 5]; console.log(...x); // bad new (Function.prototype.bind.apply(Date, [null, 2016, 8, 5])); // good new Date(...[2016, 8, 5]);
-
7.15 Functions with multiline signatures, or invocations, should be indented just like every other multiline list in this guide: with each item on a line by itself, with a trailing comma on the last item. eslint:
function-paren-newline
-
7.15 여러 줄의 시그니처 또는 호출을 취하는 함수는 이 가이드에 있는 다른 것들처럼 들여쓰기가 되어야 합니다. 한줄에 각 항목을 하나씩 두고, 마지막 항목에 쉼표를 넣습니다. eslint:
function-paren-newline
// bad function foo(bar, baz, quux) { // ... } // good function foo( bar, baz, quux, ) { // ... } // bad console.log(foo, bar, baz); // good console.log( foo, bar, baz, );
-
8.1 When you must use an anonymous function (as when passing an inline callback), use arrow function notation. eslint:
prefer-arrow-callback
,arrow-spacing
-
8.1 (인라인 콜백을 전달하는 듯한) 익명함수를 사용할 때는 화살표 함수 표현을 사용하세요. eslint:
prefer-arrow-callback
,arrow-spacing
Why? It creates a version of the function that executes in the context of
this
, which is usually what you want, and is a more concise syntax.왜? 화살표 함수는 그 컨텍스트의
this
에서 실행하는 버전의 함수를 만듭니다. 이것은 보통 원하는대로 작동하고, 보다 간결합니다.Why not? If you have a fairly complicated function, you might move that logic out into its own named function expression.
사용해야만 하지 않아? 복잡한 함수에서 로직을 정의한 함수의 바깥으로 이동하고 싶을 때.
// 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; });
-
8.2 If the function body consists of a single statement returning an expression without side effects, omit the braces and use the implicit return. Otherwise, keep the braces and use a
return
statement. eslint:arrow-parens
,arrow-body-style
-
8.2 하나의 식으로 구성된 함수가 부작용이 없는 표현식을 반환하는 경우, 중괄호를 생략하고 암시적 반환을 사용할 수 있습니다. 그 외에는 중괄호를 그대로 두고,
return
문도 사용하세요. eslint:arrow-parens
,arrow-body-style
Why? Syntactic sugar. It reads well when multiple functions are chained together.
왜? 문법적 설탕이니까요. 여러 함수가 연결된 경우 읽기 쉬워집니다.
// bad [1, 2, 3].map(number => { const nextNumber = number + 1; `A string containing the ${nextNumber}.`; }); // good [1, 2, 3].map(number => `A string containing the ${number}.`); // good [1, 2, 3].map((number) => { const nextNumber = number + 1; return `A string containing the ${nextNumber}.`; }); // good [1, 2, 3].map((number, index) => ({ [index]: number, })); // No implicit return with side effects function foo(callback) { const val = callback(); if (val === true) { // Do something if callback returns true } } let bool = false; // bad foo(() => bool = true); // good foo(() => { bool = true; });
-
8.3 In case the expression spans over multiple lines, wrap it in parentheses for better readability.
-
8.3 표현식이 여러 줄에 걸쳐 있을 때는 가독성을 높이기 위해 소괄호로 감싸주세요.
Why? It shows clearly where the function starts and ends.
왜? 함수의 시작과 끝 부분을 알기 쉽게 해주기 때문입니다.
// bad ['get', 'post', 'put'].map(httpMethod => Object.prototype.hasOwnProperty.call( httpMagicObjectWithAVeryLongName, httpMethod, ) ); // good ['get', 'post', 'put'].map(httpMethod => ( Object.prototype.hasOwnProperty.call( httpMagicObjectWithAVeryLongName, httpMethod, ) ));
-
8.4 If your function takes a single argument and doesn’t use braces, omit the parentheses. Otherwise, always include parentheses around arguments for clarity and consistency. Note: it is also acceptable to always use parentheses, in which case use the “always” option for eslint or do not include
disallowParenthesesAroundArrowParam
for jscs. eslint:arrow-parens
-
8.4 함수의 인자가 하나인 경우 소괄호를 생략할 수 있습니다. 그 외에는 명확성과 일관성을 위해 항상 괄호를 사용하세요. 참고: 모든 경우에 괄호를 사용하는 것도 괜찮습니다. 이 경우 eslint에서 “always” 옵션을 사용하거나 jscs에
disallowParenthesesAroundArrowParam
를 포함하지 마세요. eslint:arrow-parens
Why? Less visual clutter.
왜? 별로 보기 어렵지 않기 때문입니다.
// bad [1, 2, 3].map((x) => x * x); // good [1, 2, 3].map(x => x * x); // good [1, 2, 3].map(number => ( `A long string with the ${number}. It’s so long that we don’t want it to take up space on the .map line!` )); // bad [1, 2, 3].map(x => { const y = x + 1; return x * y; }); // good [1, 2, 3].map((x) => { const y = x + 1; return x * y; });
-
8.5 Avoid confusing arrow function syntax (
=>
) with comparison operators (<=
,>=
). eslint:no-confusing-arrow
-
8.5 화살표 함수 구문(
=>
)과 비교 연산자(<=
,>=
)를 헷갈리게 하지 마세요. eslint:no-confusing-arrow
// bad const itemHeight = item => item.height > 256 ? item.largeSize : item.smallSize; // bad const itemHeight = (item) => item.height > 256 ? item.largeSize : item.smallSize; // good const itemHeight = item => (item.height > 256 ? item.largeSize : item.smallSize); // good const itemHeight = (item) => { const { height, largeSize, smallSize } = item; return height > 256 ? largeSize : smallSize; };
-
8.6 Enforce the location of arrow function bodies with implicit returns. eslint:
implicit-arrow-linebreak
-
8.6 암시적 반환을 하는 화살표 함수 몸체의 위치를 적절히 설정하세요. eslint:
implicit-arrow-linebreak
// bad (foo) => bar; (foo) => (bar); // good (foo) => bar; (foo) => (bar); (foo) => ( bar )
-
9.1 Always use
class
. Avoid manipulatingprototype
directly. -
9.1
prototype
을 직접 조작하는것을 피하고 항상class
를 사용하세요.Why?
class
syntax is more concise and easier to reason about.왜?
class
구문은 간결하고 의미를 알기 쉽기 때문입니다.// bad function Queue(contents = []) { this.queue = [...contents]; } Queue.prototype.pop = function () { const value = this.queue[0]; this.queue.splice(0, 1); return value; }; // good class Queue { constructor(contents = []) { this.queue = [...contents]; } pop() { const value = this.queue[0]; this.queue.splice(0, 1); return value; } }
-
9.2 Use
extends
for inheritance. -
9.2 상속에는
extends
를 사용하세요.Why? It is a built-in way to inherit prototype functionality without breaking
instanceof
.왜?
instanceof
를 파괴하지 않고 프토로타입 상속을 하기 위해 내장된 방법이기 때문입니다.// bad const inherits = require('inherits'); function PeekableQueue(contents) { Queue.apply(this, contents); } inherits(PeekableQueue, Queue); PeekableQueue.prototype.peek = function () { return this.queue[0]; }; // good class PeekableQueue extends Queue { peek() { return this.queue[0]; } }
-
9.3 Methods can return
this
to help with method chaining. -
9.3 메소드가
this
를 반환하게 함으로써 메소드 체이닝울 할 수 있습니다.// bad Jedi.prototype.jump = function () { this.jumping = true; return true; }; Jedi.prototype.setHeight = function (height) { this.height = height; }; const luke = new Jedi(); luke.jump(); // => true luke.setHeight(20); // => undefined // good class Jedi { jump() { this.jumping = true; return this; } setHeight(height) { this.height = height; return this; } } const luke = new Jedi(); luke.jump() .setHeight(20);
-
9.4 It’s okay to write a custom
toString()
method, just make sure it works successfully and causes no side effects. -
9.4
toString()
을 사용해도 되지만, 올바르게 동작하는지와 부작용이 없는지 확인해 주세요.class Jedi { constructor(options = {}) { this.name = options.name || 'no name'; } getName() { return this.name; } toString() { return `Jedi - ${this.getName()}`; } }
-
9.5 Classes have a default constructor if one is not specified. An empty constructor function or one that just delegates to a parent class is unnecessary. eslint:
no-useless-constructor
-
9.5 클래스는 생성자가 명시되지 않은 경우 기본 생성자를 갖습니다. 빈 생성자 함수나 부모 클래스로 위임하는 함수는 불필요합니다. eslint:
no-useless-constructor
// bad class Jedi { constructor() {} getName() { return this.name; } } // bad class Rey extends Jedi { constructor(...args) { super(...args); } } // good class Rey extends Jedi { constructor(...args) { super(...args); this.name = 'Rey'; } }
-
9.6 Avoid duplicate class members. eslint:
no-dupe-class-members
-
9.6 중복되는 클래스 멤버를 만들지 마세요. eslint:
no-dupe-class-members
Why? Duplicate class member declarations will silently prefer the last one - having duplicates is almost certainly a bug.
왜? 중복된 클래스 멤버를 선언하는 것은 암묵적으로 마지막 것을 취하는 것입니다. 중복은 거의 확실히 버그입니다.
// bad class Foo { bar() { return 1; } bar() { return 2; } } // good class Foo { bar() { return 1; } } // good class Foo { bar() { return 2; } }
-
10.1 Always use modules (
import
/export
) over a non-standard module system. You can always transpile to your preferred module system. -
10.1 비표준 모듈 시스템이 아니라면 항상 모듈(
import
/export
)을 사용하세요. 이를 통해 선호하는 모듈 시스템에 언제든 옮겨갈 수 있습니다.Why? Modules are the future, let’s start using the future now.
왜? 모듈은 미래입니다. 지금 그 미래를 사용해 시작합니다.
// bad const AirbnbStyleGuide = require('./AirbnbStyleGuide'); module.exports = AirbnbStyleGuide.es6; // ok import AirbnbStyleGuide from './AirbnbStyleGuide'; export default AirbnbStyleGuide.es6; // best import { es6 } from './AirbnbStyleGuide'; export default es6;
-
10.2 Do not use wildcard imports.
-
10.2 와일드카드 import는 사용하지 마세요.
Why? This makes sure you have a single default export.
왜? single default export임을 확실히 할 수 있습니다.
// bad import * as AirbnbStyleGuide from './AirbnbStyleGuide'; // good import AirbnbStyleGuide from './AirbnbStyleGuide';
-
10.3 And do not export directly from an import.
-
10.3 import문으로부터 직접 export하지 마세요.
Why? Although the one-liner is concise, having one clear way to import and one clear way to export makes things consistent.
왜? 한줄이 간결하기는 하지만, 명확한 import와 명확한 export를 통해 일관성을 가질 수 있기 때문입니다.
// bad // filename es6.js export { es6 as default } from './AirbnbStyleGuide'; // good // filename es6.js import { es6 } from './AirbnbStyleGuide'; export default es6;
-
10.4 Only import from a path in one place. eslint:
no-duplicate-imports
-
10.4 같은 경로는 한 곳에서 improt하세요. eslint:
no-duplicate-imports
Why? Having multiple lines that import from the same path can make code harder to maintain.
왜? 같은 경로에서 import하는 여러 줄의 코드는 유지보수를 어렵게 만듭니다.
// bad import foo from 'foo'; // … some other imports … // import { named1, named2 } from 'foo'; // good import foo, { named1, named2 } from 'foo'; // good import foo, { named1, named2, } from 'foo';
-
10.5 Do not export mutable bindings. eslint:
import/no-mutable-exports
-
10.5 변경 가능한 바인딩을 export하지 마세요. eslint:
import/no-mutable-exports
Why? Mutation should be avoided in general, but in particular when exporting mutable bindings. While this technique may be needed for some special cases, in general, only constant references should be exported.
왜? 변경은 일반적으로 피해야 하지만, 변경 가능한 바인딩을 export할 때는 특히 그렇습니다. 이 기술이 어떤 특별한 상황에만 필요할 수도 있지만, 일반적으로는 상수 참조만 export되어야 합니다.
// bad let foo = 3; export { foo }; // good const foo = 3; export { foo };
-
10.6 In modules with a single export, prefer default export over named export. eslint:
import/prefer-default-export
-
10.6 한가지만 export하는 모듈에서는 이름 붙여진 export보다는 default export를 사용하세요. eslint:
import/prefer-default-export
Why? To encourage more files that only ever export one thing, which is better for readability and maintainability.
왜? 하나만 export하는 파일의 가독성과 유지보수성이 더 좋기 때문입니다.
// bad export function foo() {} // good export default function foo() {}
-
10.7 Put all
import
s above non-import statements. eslint:import/first
-
10.7 모든
import
구문을 다른 구문들 위에 두세요. eslint:import/first
Why? Since
import
s are hoisted, keeping them all at the top prevents surprising behavior.왜?
import
구문은 호이스트되기 때문에 이것을 가장 위에 두면 예상치 못한 결과를 막을 수 있습니다.// bad import foo from 'foo'; foo.init(); import bar from 'bar'; // good import foo from 'foo'; import bar from 'bar'; foo.init();
-
10.8 Multiline imports should be indented just like multiline array and object literals.
-
10.8 여러 줄에 걸친 import는 여러 줄의 배열이나 객체 리터럴처럼 들여쓰기하세요.
Why? The curly braces follow the same indentation rules as every other curly brace block in the style guide, as do the trailing commas.
왜? 스타일 가이드에 있는 다른 모든 중괄호 블록들 처럼 중괄호는 같은 들여쓰기 규칙을 따릅니다. 콤마가 그렇듯이 말이죠.
// bad import {longNameA, longNameB, longNameC, longNameD, longNameE} from 'path'; // good import { longNameA, longNameB, longNameC, longNameD, longNameE, } from 'path';
-
10.9 Disallow Webpack loader syntax in module import statements.
-
10.9 모듈 import 구문에서 Webpack loader 구문을 사용하지 마세요. eslint:
import/no-webpack-loader-syntax
Why? Since using Webpack syntax in the imports couples the code to a module bundler. Prefer using the loader syntax in
webpack.config.js
.왜? import에서 Webpack 구문을 사용하면 이 코드가 모듈 번들러에 연결되기 때문입니다. loader 구문은
webpack.config.js
에서 사용하세요.// bad import fooSass from 'css!sass!foo.scss'; import barCss from 'style!css!bar.css'; // good import fooSass from 'foo.scss'; import barCss from 'bar.css';
-
11.1 Don’t use iterators. Prefer JavaScript’s higher-order functions instead of loops like
for-in
orfor-of
. eslint:no-iterator
no-restricted-syntax
-
11.1 이터레이터를 사용하지 마세요.
for-in
이나for-of
같은 루프 대신 자바스크립트의 고급함수를 사용하세요. eslint:no-iterator
no-restricted-syntax
Why? This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side effects.
왜? 고급함수는 불변 규칙을 적용합니다. 부작용에 대해 추측하는 것보다 값을 반환하는 순수 함수를 다루는 것이 더 간단합니다.
Use
map()
/every()
/filter()
/find()
/findIndex()
/reduce()
/some()
/ ... to iterate over arrays, andObject.keys()
/Object.values()
/Object.entries()
to produce arrays so you can iterate over objects.배열을 이터레이트할 때
map()
/every()
/filter()
/find()
/findIndex()
/reduce()
/some()
/ ... 를 사용하세요. 배열을 생성할 때는Object.keys()
/Object.values()
/Object.entries()
를 사용해서 모든 객체를 이터레이트 할 수 있습니다.const numbers = [1, 2, 3, 4, 5]; // bad let sum = 0; for (let num of numbers) { sum += num; } sum === 15; // good let sum = 0; numbers.forEach((num) => { sum += num; }); sum === 15; // best (use the functional force) const sum = numbers.reduce((total, num) => total + num, 0); sum === 15; // bad const increasedByOne = []; for (let i = 0; i < numbers.length; i++) { increasedByOne.push(numbers[i] + 1); } // good const increasedByOne = []; numbers.forEach((num) => { increasedByOne.push(num + 1); }); // best (keeping it functional) const increasedByOne = numbers.map(num => num + 1);
-
11.2 Don’t use generators for now.
-
11.2 지금은 제너레이터를 사용하지 마세요.
Why? They don’t transpile well to ES5.
왜? ES5로 잘 트랜스파일하지 않기 때문입니다.
-
11.3 If you must use generators, or if you disregard our advice, make sure their function signature is spaced properly. eslint:
generator-star-spacing
-
11.3 만약 반드시 제너레이터를 사용해야 하거나 우리의 조언을 무시하는 경우, 함수 시그니처의 공백이 적절한지 확인하세요. eslint:
generator-star-spacing
Why?
function
and*
are part of the same conceptual keyword -*
is not a modifier forfunction
,function*
is a unique construct, different fromfunction
.왜?
function
과*
는 같은 개념의 키워드입니다. -*
은function
,function*
의 제어자가 아니며, 이들은function
과 다른 고유한 구조입니다.// bad function * foo() { // ... } // bad const bar = function * () { // ... }; // bad const baz = function *() { // ... }; // bad const quux = function*() { // ... }; // bad function*foo() { // ... } // bad function *foo() { // ... } // very bad function * foo() { // ... } // very bad const wat = function * () { // ... }; // good function* foo() { // ... } // good const foo = function* () { // ... };
-
12.1 Use dot notation when accessing properties. eslint:
dot-notation
-
12.1 속성에 접근할 때는 마침표를 사용하세요. eslint:
dot-notation
const luke = { jedi: true, age: 28, }; // bad const isJedi = luke['jedi']; // good const isJedi = luke.jedi;
-
12.2 Use bracket notation
[]
when accessing properties with a variable. -
12.2 변수를 사용해 속성에 접근할 때는 대괄호
[]
를 사용하세요.const luke = { jedi: true, age: 28, }; function getProp(prop) { return luke[prop]; } const isJedi = getProp('jedi');
-
12.3 Use exponentiation operator
**
when calculating exponentiations. eslint:no-restricted-properties
. -
12.3 제곱 계산을 할 때는 제곱 연산자
**
을 사용하세요. eslint:no-restricted-properties
.// bad const binary = Math.pow(2, 10); // good const binary = 2 ** 10;
-
13.1 Always use
const
orlet
to declare variables. Not doing so will result in global variables. We want to avoid polluting the global namespace. Captain Planet warned us of that. eslint:no-undef
prefer-const
-
13.1 변수를 선언할 때는 항상
const
나let
을 사용하세요. 이렇게 하지 않으면 전역 변수로 선언됩니다. 우리는 전역 네임스페이스를 오염시키지 않기를 바랍니다. Captain Planet이 우리에게 경고했어요. eslint:no-undef
prefer-const
// bad superPower = new SuperPower(); // good const superPower = new SuperPower();
-
13.2 Use one
const
orlet
declaration per variable. eslint:one-var
-
13.2 하나의 변수에 하나의
const
또는let
을 사용하세요. eslint:one-var
Why? It’s easier to add new variable declarations this way, and you never have to worry about swapping out a
;
for a,
or introducing punctuation-only diffs. You can also step through each declaration with the debugger, instead of jumping through all of them at once.왜? 이렇게 하면 쉽게 새로운 변수를 추가할 수 있고,
,
를;
로 바꿔버리는 것에 대해 걱정할 필요가 없습니다. 또한 한번에 모든 선언을 건너뛰는 대신 디버거를 사용해 각 선언을 단계별로 살펴볼 수 있습니다.// bad const items = getItems(), goSportsTeam = true, dragonball = 'z'; // bad // (compare to above, and try to spot the mistake) const items = getItems(), goSportsTeam = true; dragonball = 'z'; // good const items = getItems(); const goSportsTeam = true; const dragonball = 'z';
-
13.3 Group all your
const
s and then group all yourlet
s. -
13.3
const
를 그룹화한 다음에let
을 그룹화 하세요.Why? This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables.
왜? 이전에 할당한 변수에 대해 새 변수를 추가하는 경우 유용하기 때문입니다.
// bad let i, len, dragonball, items = getItems(), goSportsTeam = true; // bad let i; const items = getItems(); let dragonball; const goSportsTeam = true; let len; // good const goSportsTeam = true; const items = getItems(); let dragonball; let i; let length;
-
13.4 Assign variables where you need them, but place them in a reasonable place.
-
13.4 필요한 곳에서 변수를 할당하되, 합당한 곳에 두세요.
Why?
let
andconst
are block scoped and not function scoped.왜?
let
과const
는 블록스코프이기 때문입니다. 함수스코프가 아닙니다.// bad - unnecessary function call function checkName(hasName) { const name = getName(); if (hasName === 'test') { return false; } if (name === 'test') { this.setName(''); return false; } return name; } // good function checkName(hasName) { if (hasName === 'test') { return false; } const name = getName(); if (name === 'test') { this.setName(''); return false; } return name; }
-
13.5 Don’t chain variable assignments. eslint:
no-multi-assign
-
13.5 변수 할당 체이닝을 하지 마세요. eslint:
no-multi-assign
Why? Chaining variable assignments creates implicit global variables.
왜? 변수 할당 체이닝은 암시적인 전역 변수를 만들기 때문입니다.
// bad (function example() { // JavaScript interprets this as // let a = ( b = ( c = 1 ) ); // The let keyword only applies to variable a; variables b and c become // global variables. let a = b = c = 1; }()); console.log(a); // throws ReferenceError console.log(b); // 1 console.log(c); // 1 // good (function example() { let a = 1; let b = a; let c = a; }()); console.log(a); // throws ReferenceError console.log(b); // throws ReferenceError console.log(c); // throws ReferenceError // the same applies for `const`
-
13.6 Avoid using unary increments and decrements (
++
,--
). eslintno-plusplus
-
13.6 단항 증감 연산자(
++
,--
)를 사용하지 마세요. eslintno-plusplus
Why? Per the eslint documentation, unary increment and decrement statements are subject to automatic semicolon insertion and can cause silent errors with incrementing or decrementing values within an application. It is also more expressive to mutate your values with statements like
num += 1
instead ofnum++
ornum ++
. Disallowing unary increment and decrement statements also prevents you from pre-incrementing/pre-decrementing values unintentionally which can also cause unexpected behavior in your programs.왜? eslint 문서에 따르면, 단항 증감 구문은 자동으로 세미콜론을 삽입하며, 어플리케이션에서 값을 증감할 때 오류를 일으킬 수 있습니다. 또한
num += 1
과 같은 구문을 통해 값을 변경하는 것이num++
이나num ++
와 같은 구문을 사용하는 것보다 더 의미있는 일이라고 생각합니다. 단항 증감 구문을 사용하지 않으면 프로그램에서 예기치 않은 동작을 일으키는 전위 증감 연산을 막을 수 있습니다.// bad const array = [1, 2, 3]; let num = 1; num++; --num; let sum = 0; let truthyCount = 0; for (let i = 0; i < array.length; i++) { let value = array[i]; sum += value; if (value) { truthyCount++; } } // good const array = [1, 2, 3]; let num = 1; num += 1; num -= 1; const sum = array.reduce((a, b) => a + b, 0); const truthyCount = array.filter(Boolean).length;
-
13.7 Avoid linebreaks before or after
=
in an assignment. If your assignment violatesmax-len
, surround the value in parens. eslintoperator-linebreak
. -
13.7 값을 할당할 때
=
의 앞 또는 뒤에서 줄바꿈을 하지 마세요. 만약 할당이max-len
을 넘기는 경우, 값을 괄호로 둘러싸세요. eslintoperator-linebreak
.Why? Linebreaks surrounding
=
can obfuscate the value of an assignment.왜?
=
주위에서 줄바꿈을 하는 것은 할당 값을 모호하게 합니다.// bad const foo = superLongLongLongLongLongLongLongLongFunctionName(); // bad const foo = 'superLongLongLongLongLongLongLongLongString'; // good const foo = ( superLongLongLongLongLongLongLongLongFunctionName() ); // good const foo = 'superLongLongLongLongLongLongLongLongString';
-
13.8 Disallow unused variables. eslint:
no-unused-vars
-
13.8 사용되지 않는 변수를 남겨두지 마세요. eslint:
no-unused-vars
Why? Variables that are declared and not used anywhere in the code are most likely an error due to incomplete refactoring. Such variables take up space in the code and can lead to confusion by readers.
왜? 선언되었지만 사용되지 않는 변수는 완벽하지 않은 리팩토링으로 인한 에러일 수 있습니다. 그런 변수는 코드의 자리를 차지하며, 읽는 사람이 혼란에 빠지도록 만듭니다.
// bad var some_unused_var = 42; // Write-only variables are not considered as used. var y = 10; y = 5; // A read for a modification of itself is not considered as used. var z = 0; z = z + 1; // Unused function arguments. function getX(x, y) { return x; } // good function getXPlusY(x, y) { return x + y; } var x = 1; var y = a + 2; alert(getXPlusY(x, y)); // 'type' is ignored even if unused because it has a rest property sibling. // This is a form of extracting an object that omits the specified keys. var { type, ...coords } = data; // 'coords' is now the 'data' object without its 'type' property.
-
14.1
var
declarations get hoisted to the top of their closest enclosing function scope, their assignment does not.const
andlet
declarations are blessed with a new concept called Temporal Dead Zones (TDZ). It’s important to know why typeof is no longer safe. -
14.1
var
선언은 할당없이 가장 가까운 함수 스코프의 꼭대기에 호이스트됩니다.const
와let
선언은 Temporal Dead Zones (TDZ)라고 불리는 새로운 개념의 혜택을 받습니다. 왜 typeof는 더 이상 안전하지 않은가에 대해서 알고있는 것이 중요합니다.// we know this wouldn’t work (assuming there // is no notDefined global variable) // (notDefined 가 글로벌변수에 존재하지 않는다고 판정한 경우) // 잘 동작하지 않습니다 function example() { console.log(notDefined); // => throws a ReferenceError } // creating a variable declaration after you // reference the variable will work due to // variable hoisting. Note: the assignment // value of `true` is not hoisted. // 그 변수를 참조하는 코드의 뒤에서 그 변수를 선언한 경우 // 변수가 hoist 된 상태에서 동작합니다. // 주의:`true` 라는 값 자체는 호이스트되지 않습니다. function example() { console.log(declaredButNotAssigned); // => undefined var declaredButNotAssigned = true; } // the interpreter is hoisting the variable // declaration to the top of the scope, // which means our example could be rewritten as: // 인터프리터는 변수선언을 스코프의 선두에 호이스트합니다 // 위의 예는 다음과 같이 다시 쓸수 있습니다: function example() { let declaredButNotAssigned; console.log(declaredButNotAssigned); // => undefined declaredButNotAssigned = true; } // using const and let // const와 let을 이용한 경우 function example() { console.log(declaredButNotAssigned); // => throws a ReferenceError console.log(typeof declaredButNotAssigned); // => throws a ReferenceError const declaredButNotAssigned = true; }
-
14.2 Anonymous function expressions hoist their variable name, but not the function assignment.
-
14.2 익명함수의 경우 함수가 할당되기 전의 변수가 호이스트됩니다.
function example() { console.log(anonymous); // => undefined anonymous(); // => TypeError anonymous is not a function var anonymous = function () { console.log('anonymous function expression'); }; }
-
14.3 Named function expressions hoist the variable name, not the function name or the function body.
-
14.3 명명함수의 경우에도 똑같이 변수가 호이스트됩니다. 함수의 이름이나 본체는 호이스트되지 않습니다.
function example() { console.log(named); // => undefined named(); // => TypeError named is not a function superPower(); // => ReferenceError superPower is not defined var named = function superPower() { console.log('Flying'); }; } // the same is true when the function name // is the same as the variable name. function example() { console.log(named); // => undefined named(); // => TypeError named is not a function var named = function named() { console.log('named'); }; }
-
14.4 Function declarations hoist their name and the function body.
-
14.4 함수선언은 함수명과 함수본체가 호이스트됩니다.
function example() { superPower(); // => Flying function superPower() { console.log('Flying'); } }
-
For more information refer to JavaScript Scoping & Hoisting by Ben Cherry.
-
더 자세한 정보는 이곳을 참고해주세요 JavaScript Scoping & Hoisting by Ben Cherry.
-
15.2 Conditional statements such as the
if
statement evaluate their expression using coercion with theToBoolean
abstract method and always follow these simple rules: -
15.2
if
문과 같은 조건식은ToBoolean
메소드에 의한 강제형변환으로 평가되어 항상 다음과 같은 간단한 규칙을 따릅니다:- Objects는 true로 평가됩니다.
- Undefined는 false로 평가됩니다.
- Null는 false로 평가됩니다.
- Booleans는 boolean형의 값으로 평가됩니다.
- Numbers는 true로 평가됩니다. 하지만 +0, -0, NaN의 경우 false로 평가됩니다.
- Strings는 true로 평가됩니다. 하지만 빈 문자열
''
은, false로 평가됩니다.
if ([0] && []) { // true // an array (even an empty one) is an object, objects will evaluate to true }
-
15.3 Use shortcuts for booleans, but explicit comparisons for strings and numbers.
-
15.3 불리언 비교에는 단축형을 사용하세요. 단, 숫자나 문자열은 명시적으로 비교하세요.
// bad if (isValid === true) { // ... } // good if (isValid) { // ... } // bad if (name) { // ... } // good if (name !== '') { // ... } // bad if (collection.length) { // ... } // good if (collection.length > 0) { // ... }
- 15.4 For more information see Truth Equality and JavaScript by Angus Croll.
- 15.4 더 자세한 정보는 이곳을 참고해주세요. Truth Equality and JavaScript by Angus Croll.
-
15.5 Use braces to create blocks in
case
anddefault
clauses that contain lexical declarations (e.g.let
,const
,function
, andclass
). eslint:no-case-declarations
-
15.5 렉시컬 선언 (e.g.
let
,const
,function
, andclass
)을 포함하는case
와default
구문 안에 블록을 만들 때는 괄호를 사용하세요. eslint:no-case-declarations
Why? Lexical declarations are visible in the entire
switch
block but only get initialized when assigned, which only happens when itscase
is reached. This causes problems when multiplecase
clauses attempt to define the same thing.왜? 렉시컬 선언은
switch
블록 전체에서 접근할 수 있지만, 할당된 경우에만 초기화됩니다.case
에 다달았을 때 말이죠. 이것은 여러case
구문이 같은 것을 정의하려 할 때 문제를 일으킵니다.// bad switch (foo) { case 1: let x = 1; break; case 2: const y = 2; break; case 3: function f() { // ... } break; default: class C {} } // good switch (foo) { case 1: { let x = 1; break; } case 2: { const y = 2; break; } case 3: { function f() { // ... } break; } case 4: bar(); break; default: { class C {} } }
-
15.6 Ternaries should not be nested and generally be single line expressions. eslint:
no-nested-ternary
-
15.6 삼항 연산자는 중첩되어서는 안되며, 일반적으로 한 줄에 표현해야 합니다. eslint:
no-nested-ternary
// bad const foo = maybe1 > maybe2 ? "bar" : value1 > value2 ? "baz" : null; // split into 2 separated ternary expressions const maybeNull = value1 > value2 ? 'baz' : null; // better const foo = maybe1 > maybe2 ? 'bar' : maybeNull; // best const foo = maybe1 > maybe2 ? 'bar' : maybeNull;
-
15.7 Avoid unneeded ternary statements. eslint:
no-unneeded-ternary
-
15.7 불필요한 삼항 연산자를 사용하지 마세요. eslint:
no-unneeded-ternary
// bad const foo = a ? a : b; const bar = c ? true : false; const baz = c ? false : true; // good const foo = a || b; const bar = !!c; const baz = !c;
-
15.8 When mixing operators, enclose them in parentheses. The only exception is the standard arithmetic operators (
+
,-
,*
, &/
) since their precedence is broadly understood. eslint:no-mixed-operators
-
15.8 연산자를 섞어 사용할 때 해당 연산자들을 괄호로 둘러싸세요. 유일한 예외는 산술 연산자 (
+
,-
,*
, &/
)입니다. 이들의 우선순위가 광범위하게 이해되기 때문입니다. eslint:no-mixed-operators
Why? This improves readability and clarifies the developer’s intention.
왜? 이렇게 하면 코드가 더 읽기 쉬워지며, 개발자의 의도가 명확해지기 때문입니다.
// bad const foo = a && b < 0 || c > 0 || d + 1 === 0; // bad const bar = a ** b - 5 % d; // bad // one may be confused into thinking (a || b) && c if (a || b && c) { return d; } // good const foo = (a && b < 0) || c > 0 || (d + 1 === 0); // good const bar = (a ** b) - (5 % d); // good if (a || (b && c)) { return d; } // good const bar = a + b / c * d;
- 16.1 Use braces with all multi-line blocks. eslint:
nonblock-statement-body-position
-
16.1 여러 줄의 블록에는 중괄호를 사용하세요. eslint:
nonblock-statement-body-position
// bad if (test) return false; // good if (test) return false; // good if (test) { return false; } // bad function foo() { return false; } // good function bar() { return false; }
-
16.2 If you're using multi-line blocks with
if
andelse
, putelse
on the same line as yourif
block’s closing brace. eslint:brace-style
-
16.2 여러 줄의
if
와else
문을 사용할 때는else
를if
블록의 닫는 중괄호와 같은 줄에 두세요. eslint:brace-style
// bad if (test) { thing1(); thing2(); } else { thing3(); } // good if (test) { thing1(); thing2(); } else { thing3(); }
-
16.3 If an
if
block always executes areturn
statement, the subsequentelse
block is unnecessary. Areturn
in anelse if
block following anif
block that contains areturn
can be separated into multipleif
blocks. eslint:no-else-return
-
16.3 만약
if
블록이 항상return
구문을 실행시킨다면,else
블록은 불필요합니다.return
을 포함한if
블록을 잇는else if
블록 안에return
구문이 있으면 여러if
블록으로 나눠질 수 있습니다. eslint:no-else-return
// bad function foo() { if (x) { return x; } else { return y; } } // bad function cats() { if (x) { return x; } else if (y) { return y; } } // bad function dogs() { if (x) { return x; } else { if (y) { return y; } } } // good function foo() { if (x) { return x; } return y; } // good function cats() { if (x) { return x; } if (y) { return y; } } // good function dogs(x) { if (x) { if (z) { return y; } } else { return z; } }
-
17.1 In case your control statement (
if
,while
etc.) gets too long or exceeds the maximum line length, each (grouped) condition could be put into a new line. The logical operator should begin the line. -
17.1 제어문 (
if
,while
등)이 너무 길거나 최대 길이를 넘긴 경우, 각 조건을 새로운 줄에 두세요. 논리 연산자는 줄의 시작부분에 있어야 합니다.Why? Requiring operators at the beginning of the line keeps the operators aligned and follows a pattern similar to method chaining. This also improves readability by making it easier to visually follow complex logic.
왜? 줄의 맨 처음에 연산자를 두면 연산자의 정렬을 유지하고, 메소드 체이닝과 비슷한 패턴을 따를 수 있습니다. 또, 이렇게 하면 복잡한 로직을 쉽게 볼 수 있도록 만들어 가독성을 높입니다.
// bad if ((foo === 123 || bar === 'abc') && doesItLookGoodWhenItBecomesThatLong() && isThisReallyHappening()) { thing1(); } // bad if (foo === 123 && bar === 'abc') { thing1(); } // bad if (foo === 123 && bar === 'abc') { thing1(); } // bad if ( foo === 123 && bar === 'abc' ) { thing1(); } // good if ( foo === 123 && bar === 'abc' ) { thing1(); } // good if ( (foo === 123 || bar === 'abc') && doesItLookGoodWhenItBecomesThatLong() && isThisReallyHappening() ) { thing1(); } // good if (foo === 123 && bar === 'abc') { thing1(); }
-
17.2 Don't use selection operators in place of control statements.
-
17.2. 선택 연산자를 제어 구문 대신 쓰지 마세요.
// bad !isRunning && startRunning(); // good if (!isRunning) { startRunning(); }
-
18.1 Use
/** ... */
for multi-line comments. -
18.1 여러 줄에 걸친 주석을 쓸 때는
/** ... */
을 사용하세요.// bad // make() returns a new element // based on the passed in tag name // // @param {String} tag // @return {Element} element function make(tag) { // ... return element; } // good /** * make() returns a new element * based on the passed-in tag name */ function make(tag) { // ... return element; }
-
18.2 Use
//
for single line comments. Place single line comments on a newline above the subject of the comment. Put an empty line before the comment unless it’s on the first line of a block. -
18.2 한줄 주석을 쓸 때는
//
을 사용하세요. 주석 전에는 빈 행을 넣어주세요.// bad const active = true; // is current tab // good // is current tab const active = true; // bad function getType() { console.log('fetching type...'); // set the default type to 'no type' const type = this.type || 'no type'; return type; } // good function getType() { console.log('fetching type...'); // set the default type to 'no type' const type = this.type || 'no type'; return type; } // also good function getType() { // set the default type to 'no type' const type = this.type || 'no type'; return type; }
-
18.3 Start all comments with a space to make it easier to read. eslint:
spaced-comment
-
18.3 모든 주석은 공백으로 시작해야 합니다. eslint:
spaced-comment
// bad //is current tab const active = true; // good // is current tab const active = true; // bad /** *make() returns a new element *based on the passed-in tag name */ function make(tag) { // ... return element; } // good /** * make() returns a new element * based on the passed-in tag name */ function make(tag) { // ... return element; }
- 18.4 Prefixing your comments with
FIXME
orTODO
helps other developers quickly understand if you're pointing out a problem that needs to be revisited, or if you're suggesting a solution to the problem that needs to be implemented. These are different than regular comments because they are actionable. The actions areFIXME: -- need to figure this out
orTODO: -- need to implement
. - 18.4 문제를 지적하고 재고를 촉구하는 경우나 문제의 해결책을 제안하는 경우 등에는 주석 앞에
FIXME
나TODO
를 붙임으로써 다른 개발자의 빠른 이해를 도울수 있습니다. 이런 것들은 어떤 행동을 따른다는 의미로 통상의 주석와는 다릅니다. 행동이라는 것은FIXME -- 해결이 필요
또는TODO -- 구현이 필요
를 뜻합니다.
-
18.5 Use
// FIXME:
to annotate problems. -
18.5 문제에 대한 주석으로
// FIXME:
를 사용하세요.class Calculator extends Abacus { constructor() { super(); // FIXME: shouldn’t use a global here // FIXME: 전역 변수를 사용해서는 안 됨 total = 0; } }
-
18.6 Use
// TODO:
to annotate solutions to problems. -
18.6 문제의 해결책에 대한 주석으로
// TODO:
를 사용하세요.class Calculator extends Abacus { constructor() { super(); // TODO: total should be configurable by an options param // TODO: total은 옵션 파라메터로 설정해야함 this.total = 0; } }
-
19.1 Use soft tabs (space character) set to 2 spaces. eslint:
indent
-
19.1 탭은 공백문자 2개로 설정하세요. eslint:
indent
// bad function foo() { ∙∙∙∙let name; } // bad function bar() { ∙let name; } // good function baz() { ∙∙let name; }
-
19.2 Place 1 space before the leading brace. eslint:
space-before-blocks
-
19.2 주요 중괄호 앞에는 공백을 1개 넣으세요. eslint:
space-before-blocks
// bad function test(){ console.log('test'); } // good function test() { console.log('test'); } // bad dog.set('attr',{ age: '1 year', breed: 'Bernese Mountain Dog', }); // good dog.set('attr', { age: '1 year', breed: 'Bernese Mountain Dog', });
-
19.3 Place 1 space before the opening parenthesis in control statements (
if
,while
etc.). Place no space between the argument list and the function name in function calls and declarations. eslint:keyword-spacing
-
19.3 제어문 (
if
,while
등)의 소괄호 앞에는 공백을 1개 넣으세요. 함수선언이나 함수호출시 인자 리스트 앞에는 공백을 넣지 마세요. eslint:keyword-spacing
// bad if(isJedi) { fight (); } // good if (isJedi) { fight(); } // bad function fight () { console.log ('Swooosh!'); } // good function fight() { console.log('Swooosh!'); }
-
19.4 Set off operators with spaces. eslint:
space-infix-ops
-
19.4 연산자 사이에 공백을 넣으세요. eslint:
space-infix-ops
// bad const x=y+5; // good const x = y + 5;
-
19.5 End files with a single newline character. eslint:
eol-last
-
19.5 파일 끝에는 개행문자를 1개 넣으세요. eslint:
eol-last
// bad import { es6 } from './AirbnbStyleGuide'; // ... export default es6;
// bad import { es6 } from './AirbnbStyleGuide'; // ... export default es6;↵ ↵
// good import { es6 } from './AirbnbStyleGuide'; // ... export default es6;↵
-
19.6 Use indentation when making long method chains (more than 2 method chains). Use a leading dot, which emphasizes that the line is a method call, not a new statement. eslint:
newline-per-chained-call
no-whitespace-before-property
-
19.6 길게 메소드를 체이닝하는 경우 (2개 메소드 이상) 들여쓰기를 하세요. 또한 해당 줄이 새로운 구문이 아니라 메소드 호출임을 강조하는 마침표를 맨 앞에 두세요. eslint:
newline-per-chained-call
no-whitespace-before-property
// bad $('#items').find('.selected').highlight().end().find('.open').updateCount(); // bad $('#items'). find('.selected'). highlight(). end(). find('.open'). updateCount(); // good $('#items') .find('.selected') .highlight() .end() .find('.open') .updateCount(); // bad const leds = stage.selectAll('.led').data(data).enter().append('svg:svg').classed('led', true) .attr('width', (radius + margin) * 2).append('svg:g') .attr('transform', `translate(${radius + margin},${radius + margin})`) .call(tron.led); // good const leds = stage.selectAll('.led') .data(data) .enter().append('svg:svg') .classed('led', true) .attr('width', (radius + margin) * 2) .append('svg:g') .attr('transform', `translate(${radius + margin},${radius + margin})`) .call(tron.led); // good const leds = stage.selectAll('.led').data(data);
-
19.7 Leave a blank line after blocks and before the next statement.
-
19.7 구문의 앞과 블록의 뒤에는 빈 행을 두세요.
// bad if (foo) { return bar; } return baz; // good if (foo) { return bar; } return baz; // bad const obj = { foo() { }, bar() { }, }; return obj; // good const obj = { foo() { }, bar() { }, }; return obj; // bad const arr = [ function foo() { }, function bar() { }, ]; return arr; // good const arr = [ function foo() { }, function bar() { }, ]; return arr;
-
19.8 Do not pad your blocks with blank lines. eslint:
padded-blocks
-
19.8 블록에 빈 행을 끼워 넣지 마세요. eslint:
padded-blocks
// bad function bar() { console.log(foo); } // bad if (baz) { console.log(qux); } else { console.log(foo); } // bad class Foo { constructor(bar) { this.bar = bar; } } // good function bar() { console.log(foo); } // good if (baz) { console.log(qux); } else { console.log(foo); }
-
19.9 Do not add spaces inside parentheses. eslint:
space-in-parens
-
19.9 소괄호 안쪽에 공백을 두지 마세요. eslint:
space-in-parens
// bad function bar( foo ) { return foo; } // good function bar(foo) { return foo; } // bad if ( foo ) { console.log(foo); } // good if (foo) { console.log(foo); }
-
19.10 Do not add spaces inside brackets. eslint:
array-bracket-spacing
-
19.10 대괄호 안쪽에 공백을 두지 마세요. eslint:
array-bracket-spacing
// bad const foo = [ 1, 2, 3 ]; console.log(foo[ 0 ]); // good const foo = [1, 2, 3]; console.log(foo[0]);
-
19.11 Add spaces inside curly braces. eslint:
object-curly-spacing
-
19.11 중괄호 안쪽에 공백을 두세요. eslint:
object-curly-spacing
// bad const foo = {clark: 'kent'}; // good const foo = { clark: 'kent' };
-
19.12 Avoid having lines of code that are longer than 100 characters (including whitespace). Note: per above, long strings are exempt from this rule, and should not be broken up. eslint:
max-len
-
19.12 한줄의 코드가 100자를 넘기는 것을 피하세요. (공백 포함) 주의: 앞의 규칙에 따르면, 긴 문자열은 이 규칙에서 제외되며, 분리되어서는 안 됩니다. eslint:
max-len
Why? This ensures readability and maintainability.
왜? 가독성과 유지보수성을 보장해주기 때문입니다.
// bad const foo = jsonData && jsonData.foo && jsonData.foo.bar && jsonData.foo.bar.baz && jsonData.foo.bar.baz.quux && jsonData.foo.bar.baz.quux.xyzzy; // bad $.ajax({ method: 'POST', url: 'https://airbnb.com/', data: { name: 'John' } }).done(() => console.log('Congratulations!')).fail(() => console.log('You have failed this city.')); // good const foo = jsonData && jsonData.foo && jsonData.foo.bar && jsonData.foo.bar.baz && jsonData.foo.bar.baz.quux && jsonData.foo.bar.baz.quux.xyzzy; // good $.ajax({ method: 'POST', url: 'https://airbnb.com/', data: { name: 'John' }, }) .done(() => console.log('Congratulations!')) .fail(() => console.log('You have failed this city.'));
-
19.13 Require consistent spacing inside an open block token and the next token on the same line. This rule also enforces consistent spacing inside a close block token and previous token on the same line. eslint:
block-spacing
-
19.13 여는 블록 토큰과 같은 행의 다음 토큰 내의 공백을 일관성있게 하세요. 이 규칙은 닫는 블록 토큰과 같은 행의 이전 토큰에도 적용됩니다. eslint:
block-spacing
// bad function foo() {return true;} if (foo) { bar = 0;} // good function foo() { return true; } if (foo) { bar = 0; }
-
19.14 Avoid spaces before commas and require a space after commas. eslint:
comma-spacing
-
19.14 쉼표 이전에는 공백을 넣지 말고, 쉼표 이후에는 공백을 넣으세요. eslint:
comma-spacing
// bad var foo = 1,bar = 2; var arr = [1 , 2]; // good var foo = 1, bar = 2; var arr = [1, 2];
-
19.15 Enforce spacing inside of computed properties. eslint:
computed-property-spacing
-
19.15 계산된 속성 내에는 공백을 넣으세요. eslint:
computed-property-spacing
// bad obj[foo ] obj[ 'foo'] var x = {[ b ]: a} obj[foo[ bar ]] // good obj[foo] obj['foo'] var x = { [b]: a } obj[foo[bar]]
-
19.16 Enforce spacing between functions and their invocations. eslint:
func-call-spacing
-
19.16 함수와 함수 호출 사이에는 공백을 넣으세요. eslint:
func-call-spacing
// bad func (); func (); // good func();
-
19.17 Enforce spacing between keys and values in object literal properties. eslint:
key-spacing
-
19.17 객체 리터럴 속성의 키와 값 사이에는 공백을 넣으세요. eslint:
key-spacing
// bad var obj = { "foo" : 42 }; var obj2 = { "foo":42 }; // good var obj = { "foo": 42 };
- 19.18 Avoid trailing spaces at the end of lines. eslint:
no-trailing-spaces
- 19.18 해의 마지막에 공백을 남겨두지 마세요. eslint:
no-trailing-spaces
-
19.19 Avoid multiple empty lines and only allow one newline at the end of files. eslint:
no-multiple-empty-lines
-
19.19 여러 빈 행을 쓰지 마세요. 단, 파일의 마지막 행에는 빈 행을 두세요. eslint:
no-multiple-empty-lines
// bad var x = 1; var y = 2; // good var x = 1; var y = 2;
-
20.1 Leading commas: Nope. eslint:
comma-style
-
20.1 맨 앞의 쉼표: 안 됩니다. eslint:
comma-style
// bad const story = [ once , upon , aTime ]; // good const story = [ once, upon, aTime, ]; // bad const hero = { firstName: 'Ada' , lastName: 'Lovelace' , birthYear: 1815 , superPower: 'computers' }; // good const hero = { firstName: 'Ada', lastName: 'Lovelace', birthYear: 1815, superPower: 'computers', };
-
20.2 Additional trailing comma: Yup. eslint:
comma-dangle
-
20.2 끝의 쉼표: 좋아요. eslint:
comma-dangle
Why? This leads to cleaner git diffs. Also, transpilers like Babel will remove the additional trailing comma in the transpiled code which means you don’t have to worry about the trailing comma problem in legacy browsers.
왜? 이것은 깨끗한 git의 diffs로 이어집니다. 또한 Babel과 같은 트랜스파일러는 트랜스파일하는 사이에 쓸데없는 끝의 쉼표를 제거합니다. 이것은 레거시 브라우저에서의 불필요한 쉼표 문제를 고민할 필요가 없는 것을 의미합니다.
// bad - git diff without trailing comma const hero = { firstName: 'Florence', - lastName: 'Nightingale' + lastName: 'Nightingale', + inventorOf: ['coxcomb chart', 'modern nursing'] }; // good - git diff with trailing comma const hero = { firstName: 'Florence', lastName: 'Nightingale', + inventorOf: ['coxcomb chart', 'modern nursing'], };
// bad const hero = { firstName: 'Dana', lastName: 'Scully' }; const heroes = [ 'Batman', 'Superman' ]; // good const hero = { firstName: 'Dana', lastName: 'Scully', }; const heroes = [ 'Batman', 'Superman', ]; // bad function createHero( firstName, lastName, inventorOf ) { // does nothing } // good function createHero( firstName, lastName, inventorOf, ) { // does nothing } // good (note that a comma must not appear after a "rest" element) function createHero( firstName, lastName, inventorOf, ...heroArgs ) { // does nothing } // bad createHero( firstName, lastName, inventorOf ); // good createHero( firstName, lastName, inventorOf, ); // good (note that a comma must not appear after a "rest" element) createHero( firstName, lastName, inventorOf, ...heroArgs );
-
Why? When JavaScript encounters a line break without a semicolon, it uses a set of rules called Automatic Semicolon Insertion to determine whether or not it should regard that line break as the end of a statement, and (as the name implies) place a semicolon into your code before the line break if it thinks so. ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues.
왜? 자바스크립트가 세미콜론이 없는 줄바꿈을 만났을 때, 자동 세미콜론 삽입 규칙에 따라 그 줄바꿈을 구문의 끝으로 간주할지 여부를 결정하고, (이름이 암시하듯) 세미콜론을 줄바꿈 이전에 삽입합니다. ASI는 몇가지 별난 동작을 포함하고 있지만, 만약 자바스크립트가 줄바꿈을 잘못 해석한다면 코드가 망가져버릴 것입니다. 이 규칙은 새로운 기능이 자바스크립트의 일부가 되면서 더 복잡해집니다. 구문의 끝을 명시하고, 빠뜨린 세미콜론을 잡도록 linter를 설정하면 문제가 발생하는 것을 막을 수 있습니다.
// bad - raises exception const luke = {} const leia = {} [luke, leia].forEach(jedi => jedi.father = 'vader') // bad - raises exception const reaction = "No! That's impossible!" (async function meanwhileOnTheFalcon() { // handle `leia`, `lando`, `chewie`, `r2`, `c3p0` // ... }()) // bad - returns `undefined` instead of the value on the next line - always happens when `return` is on a line by itself because of ASI! function foo() { return 'search your feelings, you know it to be foo' } // good const luke = {}; const leia = {}; [luke, leia].forEach((jedi) => { jedi.father = 'vader'; }); // good const reaction = "No! That's impossible!"; (async function meanwhileOnTheFalcon() { // handle `leia`, `lando`, `chewie`, `r2`, `c3p0` // ... }()); // good function foo() { return 'search your feelings, you know it to be foo'; }
-
22.2 Strings: eslint:
no-new-wrappers
-
22.2 문자열: eslint:
no-new-wrappers
// => this.reviewScore = 9; // bad const totalScore = new String(this.reviewScore); // typeof totalScore is "object" not "string" // bad const totalScore = this.reviewScore + ''; // invokes this.reviewScore.valueOf() // bad const totalScore = this.reviewScore.toString(); // isn’t guaranteed to return a string // good const totalScore = String(this.reviewScore);
-
22.3 Numbers: Use
Number
for type casting andparseInt
always with a radix for parsing strings. eslint:radix
no-new-wrappers
-
22.3 숫자: 형변환을 하는 경우
Number
를 사용하고, 문자열을 파싱하는 경우에는 기수를 인자로 넘겨parseInt
를 사용하세요. eslint:radix
no-new-wrappers
const inputValue = '4'; // bad const val = new Number(inputValue); // bad const val = +inputValue; // bad const val = inputValue >> 0; // bad const val = parseInt(inputValue); // good const val = Number(inputValue); // good const val = parseInt(inputValue, 10);
-
22.4 If for whatever reason you are doing something wild and
parseInt
is your bottleneck and need to use Bitshift for performance reasons, leave a comment explaining why and what you're doing. -
22.4 어떤 이유로 인해
parseInt
가 병목현상을 일으켜 성능적인 이유로 비트 시프트를 사용해야 하는 경우 하려고 했던 것을 왜(why)와 무엇(what)으로 설명해 주석으로 남겨주세요.// good /** * parseInt was the reason my code was slow. * Bitshifting the String to coerce it to a * Number made it a lot faster. * 코드가 느린 원인은 parseInt였음. * 비트 시프트를 통해 문자열을 강제 형변환하여 * 성능을 개선시킴. */ const val = inputValue >> 0;
-
22.5 Note: Be careful when using bitshift operations. Numbers are represented as 64-bit values, but bitshift operations always return a 32-bit integer (source). Bitshift can lead to unexpected behavior for integer values larger than 32 bits. Discussion. Largest signed 32-bit Int is 2,147,483,647:
-
22.5 주의: 비트 연산자를 사용하는 경우. 숫자는 64비트 값으로 표현되어 있으나, 비트 시프트 연산을 한 경우 32비트 정수로 넘겨집니다. (소스). 32비트 이상의 정수를 비트 시프트하는 경우 예기치못한 현상을 야기할 수 있습니다. 토론. 부호가 포함된 32비트 정수의 최대치는 2,147,483,647입니다:
2147483647 >> 0; // => 2147483647 2147483648 >> 0; // => -2147483648 2147483649 >> 0; // => -2147483647
-
22.6 Booleans: eslint:
no-new-wrappers
-
22.6 불리언: eslint:
no-new-wrappers
const age = 0; // bad const hasAge = new Boolean(age); // good const hasAge = Boolean(age); // best const hasAge = !!age;
-
23.1 Avoid single letter names. Be descriptive with your naming. eslint:
id-length
-
23.1 한 문자로 된 이름은 피하세요. 이름으로부터 의도가 읽혀질 수 있게 해주세요. eslint:
id-length
// bad function q() { // ... } // good function query() { // ... }
-
23.2 Use camelCase when naming objects, functions, and instances. eslint:
camelcase
-
23.2 객체, 함수, 인스턴스에는 캐멀케이스(camelCase)를 사용하세요. eslint:
camelcase
// bad const OBJEcttsssss = {}; const this_is_my_object = {}; function c() {} // good const thisIsMyObject = {}; function thisIsMyFunction() {}
-
23.3 Use PascalCase only when naming constructors or classes. eslint:
new-cap
-
23.3 클래스나 생성자에는 파스칼케이스(PascalCase)를 사용하세요. eslint:
new-cap
// bad function user(options) { this.name = options.name; } const bad = new user({ name: 'nope', }); // good class User { constructor(options) { this.name = options.name; } } const good = new User({ name: 'yup', });
-
23.4 Do not use trailing or leading underscores. eslint:
no-underscore-dangle
-
23.4 언더스코어를 사용하지 마세요. eslint:
no-underscore-dangle
Why? JavaScript does not have the concept of privacy in terms of properties or methods. Although a leading underscore is a common convention to mean “private”, in fact, these properties are fully public, and as such, are part of your public API contract. This convention might lead developers to wrongly think that a change won’t count as breaking, or that tests aren’t needed. tl;dr: if you want something to be “private”, it must not be observably present.
왜? 자바스크립트는 속성이나 메소드 측면에서 은닉된 정보라는 개념을 가지고 있지 않습니다. 언더스코어는 일반적으로 “private”을 의미하지만, 사실 자바스크립트에서 해당 속성은 완전히 public하며, 이는 공공 API의 일부입니다. 이 관례는 개발자들로 하여금 변화가 깨지지 않는 것으로 간주하거나 테스트가 필요하지 않다고 잘못 생각하게 만듭니다. 요약: 만약 뭔가를 “private”하게 사용하고 싶다면, 그것은 있을 수 없는 일입니다.
// bad this.__firstName__ = 'Panda'; this.firstName_ = 'Panda'; this._firstName = 'Panda'; // good this.firstName = 'Panda'; // good, in environments where WeakMaps are available // see https://kangax.github.io/compat-table/es6/#test-WeakMap const firstNames = new WeakMap(); firstNames.set(this, 'Panda');
-
23.5 Don’t save references to
this
. Use arrow functions or Function#bind. -
23.5 참조를
this
에 저장하지 마세요. 화살표 함수나 Function#bind를 사용하세요.// bad function foo() { const self = this; return function () { console.log(self); }; } // bad function foo() { const that = this; return function () { console.log(that); }; } // good function foo() { return () => { console.log(this); }; }
-
23.6 A base filename should exactly match the name of its default export.
-
23.6 파일 이름은 default export의 이름과 일치해야 합니다.
// file 1 contents class CheckBox { // ... } export default CheckBox; // file 2 contents export default function fortyTwo() { return 42; } // file 3 contents export default function insideDirectory() {} // in some other file // bad import CheckBox from './checkBox'; // PascalCase import/export, camelCase filename import FortyTwo from './FortyTwo'; // PascalCase import/filename, camelCase export import InsideDirectory from './InsideDirectory'; // PascalCase import/filename, camelCase export // bad import CheckBox from './check_box'; // PascalCase import/export, snake_case filename import forty_two from './forty_two'; // snake_case import/filename, camelCase export import inside_directory from './inside_directory'; // snake_case import, camelCase export import index from './inside_directory/index'; // requiring the index file explicitly import insideDirectory from './insideDirectory/index'; // requiring the index file explicitly // good import CheckBox from './CheckBox'; // PascalCase export/import/filename import fortyTwo from './fortyTwo'; // camelCase export/import/filename import insideDirectory from './insideDirectory'; // camelCase export/import/directory name/implicit "index" // ^ supports both insideDirectory.js and insideDirectory/index.js
-
23.7 Use camelCase when you export-default a function. Your filename should be identical to your function’s name.
-
23.7 함수를 export-default할 때 캐멀케이스(camelCase)를 사용하세요. 파일 이름은 함수 이름과 같아야 합니다.
function makeStyleGuide() { // ... } export default makeStyleGuide;
-
23.8 Use PascalCase when you export a constructor / class / singleton / function library / bare object.
-
23.8 생성자 / 클래스 / 싱글톤 / 함수 라이브러리 / 단순 객체를 export할 때 파스칼케이스(PascalCase)를 사용하세요.
const AirbnbStyleGuide = { es6: { }, }; export default AirbnbStyleGuide;
-
23.9 Acronyms and initialisms should always be all capitalized, or all lowercased.
-
23.9 두문자어와 이니셜은 모두 대문자이거나 모두 소문자이어야 합니다.
Why? Names are for readability, not to appease a computer algorithm.
왜? 이름은 가독성을 위한 것이지 컴퓨터 알고리즘을 위한 것이 아니기 때문입니다.
// bad import SmsContainer from './containers/SmsContainer'; // bad const HttpRequests = [ // ... ]; // good import SMSContainer from './containers/SMSContainer'; // good const HTTPRequests = [ // ... ]; // also good const httpRequests = [ // ... ]; // best import TextMessageContainer from './containers/TextMessageContainer'; // best const requests = [ // ... ];
-
23.10 You may optionally uppercase a constant only if it (1) is exported, (2) is a
const
(it can not be reassigned), and (3) the programmer can trust it (and its nested properties) to never change. -
23.10 상수 이름을 대문자로 짓는 것은 해당 상수가 (1) 내보내기 될 때, (2)
const
타입일 때 (값이 재할당되지 못할 때), (3) 그 상수와 상수가 중첩된 속성이 절대 변하지 않는다는 것을 신뢰할 수 있을 때만 하세요.Why? This is an additional tool to assist in situations where the programmer would be unsure if a variable might ever change. UPPERCASE_VARIABLES are letting the programmer know that they can trust the variable (and its properties) not to change.
왜? 이것은 변수가 영원히 변하지 않는다는 것을 확신할 수 없을 때 도움을 주기 위한 추가적인 도구입니다. 대문자 변수는 변수와 변수의 속성이 변하지 않는다는 것을 프로그래머에게 알려줍니다.
-
What about all
const
variables? - This is unnecessary, so uppercasing should not be used for constants within a file. It should be used for exported constants however. -
모든
const
변수 이름을 대문자로 짓나요? - 이것은 필수사항이 아니며, 파일 내 상수 이름을 꼭 대문자로 지을 필요는 없습니다. 하지만 내보내기되는 상수 이름은 대문자로 지어야 합니다. -
What about exported objects? - Uppercase at the top level of export (e.g.
EXPORTED_OBJECT.key
) and maintain that all nested properties do not change. -
내보내기 되는 객체 이름을 대문자로 짓나요? - 최상위 수준의 내보내기를 할 때 대문자로 이름짓고 (예시:
EXPORTED_OBJECT.key
) 모든 중첩된 속성이 변경되지 않도록 유지합니다.
// bad const PRIVATE_VARIABLE = 'should not be unnecessarily uppercased within a file'; // bad export const THING_TO_BE_CHANGED = 'should obviously not be uppercased'; // bad export let REASSIGNABLE_VARIABLE = 'do not use let with uppercase variables'; // --- // allowed but does not supply semantic value export const apiKey = 'SOMEKEY'; // better in most cases export const API_KEY = 'SOMEKEY'; // --- // bad - unnecessarily uppercases key while adding no semantic value export const MAPPING = { KEY: 'value' }; // good export const MAPPING = { key: 'value' };
-
-
24.2 Do not use JavaScript getters/setters as they cause unexpected side effects and are harder to test, maintain, and reason about. Instead, if you do make accessor functions, use
getVal()
andsetVal('hello')
. -
24.2 자바스크립트 getters/setters를 사용하지 마세요. 예기치못한 부작용를 일으키고 테스트와 유지보수를 어렵게 만듭니다. 접근자 함수를 만들고 싶다면 대신,
getVal()
과setVal('hello')
를 사용하세요.// bad class Dragon { get age() { // ... } set age(value) { // ... } } // good class Dragon { getAge() { // ... } setAge(value) { // ... } }
-
24.3 If the property/method is a
boolean
, useisVal()
orhasVal()
. -
24.3 속성이나 메소드가
boolean
이라면,isVal()
이나hasVal()
을 사용하세요.// bad if (!dragon.age()) { return false; } // good if (!dragon.hasAge()) { return false; }
-
24.4 It’s okay to create
get()
andset()
functions, but be consistent. -
24.4
get()
과set()
함수를 만들되, 일관성있게 만드세요.class Jedi { constructor(options = {}) { const lightsaber = options.lightsaber || 'blue'; this.set('lightsaber', lightsaber); } set(key, val) { this[key] = val; } get(key) { return this[key]; } }
-
25.1 When attaching data payloads to events (whether DOM events or something more proprietary like Backbone events), pass an object literal (also known as a "hash") instead of a raw value. This allows a subsequent contributor to add more data to the event payload without finding and updating every handler for the event. For example, instead of:
-
25.1 (DOM이벤트나 Backbone 이벤트와 같은) 이벤트로 payload의 값을 넘길 경우 raw값 보다는 해시값을 넘겨주세요. 이렇게하면 이후 기여자가 이벤트에 관련한 모든 핸들러를 찾아서 바꾸는 대신 이벤트 payload에 값을 추가할 수 있습니다. 예를 들면 이렇게요:
// bad $(this).trigger('listingUpdated', listing.id); // ... $(this).on('listingUpdated', (e, listingID) => { // do something with listingID });
prefer:
이쪽이 더 좋습니다:
// good $(this).trigger('listingUpdated', { listingID: listing.id }); // ... $(this).on('listingUpdated', (e, data) => { // do something with data.listingID });
-
26.1 Prefix jQuery object variables with a
$
. -
26.1 제이쿼리 객체 변수의 앞에는
$
를 붙여주세요.// bad const sidebar = $('.sidebar'); // good const $sidebar = $('.sidebar'); // good const $sidebarBtn = $('.sidebar-btn');
-
26.2 Cache jQuery lookups.
-
26.2 제이쿼리의 검색결과를 캐시하세요.
// bad function setSidebar() { $('.sidebar').hide(); // ... $('.sidebar').css({ 'background-color': 'pink', }); } // good function setSidebar() { const $sidebar = $('.sidebar'); $sidebar.hide(); // ... $sidebar.css({ 'background-color': 'pink', }); }
- 26.3 For DOM queries use Cascading
$('.sidebar ul')
or parent > child$('.sidebar > ul')
. jsPerf - 26.3 DOM 검색에는
$('.sidebar ul')
이나 parent > child$('.sidebar > ul')
와 같은 캐스케이딩를 사용하세요. jsPerf
-
26.4 Use
find
with scoped jQuery object queries. -
26.4 한정된 제이쿼리 객체 쿼리에는
find
를 사용하세요.// bad $('ul', '.sidebar').hide(); // bad $('.sidebar').find('ul').hide(); // good $('.sidebar ul').hide(); // good $('.sidebar > ul').hide(); // good $sidebar.find('ul').hide();
- 화살표 함수 (Arrow Functions)
- 클래스 (Classes)
- 객체 단축형 (Object Shorthand)
- 객체 속성 단축형 (Object Concise)
- 객체 속성 계산 (Object Computed Properties)
- 템플릿 문자열 (Template Strings)
- 비구조화 (Destructuring)
- 기본 매개변수 (Default Parameters)
- 나머지 구문 (Rest)
- 배열 전개 (Array Spreads)
- Let과 Const (Let and Const)
- 제곱 연산자 (Exponentiation Operator)
- 이터레이터와 제너레이터 (Iterators and Generators)
- 모듈 (Modules)
-
28.2 Do not use TC39 proposals that have not reached stage 3.
-
28.2 스테이지3에 이르지 못하는 TC39 proposals를 사용하지 마세요.
Why? They are not finalized, and they are subject to change or to be withdrawn entirely. We want to use JavaScript, and proposals are not JavaScript yet.
왜? 그것들은 확정되지 않았습니다. 그리고 이들은 변경되거나 완전히 폐기될 수도 있습니다. 우리는 자바스크립트를 사용하기를 원하지만, proposals는 아직 자바스크립트가 아닙니다.
The Standard Library contains utilities that are functionally broken but remain for legacy reasons.
표준 라이브러리는 기능적으로 문제가 있지만 레거시 이유로 아직 남아있는 유틸리티들을 포함하고 있습니다.
-
29.1 Use
Number.isNaN
instead of globalisNaN
. eslint:no-restricted-globals
-
29.1 전역
isNaN
대신Number.isNaN
을 사용하세요. eslint:no-restricted-globals
Why? The global
isNaN
coerces non-numbers to numbers, returning true for anything that coerces to NaN. If this behavior is desired, make it explicit.왜? 전역
isNaN
은 숫자가 아닌 것을 숫자로 강제하고, NaN으로 간주되는 모든 것을 true로 반환합니다. 만약 이것을 사용해야 한다면 명시적으로 사용하세요.// bad isNaN('1.2'); // false isNaN('1.2.3'); // true // good Number.isNaN('1.2.3'); // false Number.isNaN(Number('1.2.3')); // true
-
29.2 Use
Number.isFinite
instead of globalisFinite
. eslint:no-restricted-globals
-
29.2 전역
isFinite
대신Number.isFinite
을 사용하세요. eslint:no-restricted-globals
Why? The global
isFinite
coerces non-numbers to numbers, returning true for anything that coerces to a finite number. If this behavior is desired, make it explicit.왜? 전역
isFinite
은 숫자가 아닌 것을 숫자로 강제하고, 유한한 숫자로 간주되는 모든 것을 true로 반환합니다. 만약 이것을 사용해야 한다면 명시적으로 사용하세요.// bad isFinite('2e3'); // true // good Number.isFinite('2e3'); // false Number.isFinite(parseInt('2e3', 10)); // true
- 30.2 No, but seriously:
- Whichever testing framework you use, you should be writing tests!
- Strive to write many small pure functions, and minimize where mutations occur.
- Be cautious about stubs and mocks - they can make your tests more brittle.
- We primarily use
mocha
andjest
at Airbnb.tape
is also used occasionally for small, separate modules. - 100% test coverage is a good goal to strive for, even if it’s not always practical to reach it.
- Whenever you fix a bug, write a regression test. A bug fixed without a regression test is almost certainly going to break again in the future.
- 30.2 진지하게 생각해보죠:
- On Layout & Web Performance
- String vs Array Concat
- Try/Catch Cost In a Loop
- Bang Function
- jQuery Find vs Context, Selector
- innerHTML vs textContent for script text
- Long String Concatenation
- Are Javascript functions like
map()
,reduce()
, andfilter()
optimized for traversing arrays? - Loading...
Learning ES6+
Read This
Tools
- Code Style Linters
- Neutrino preset - neutrino-preset-airbnb-base
Other Style Guides
- Google JavaScript Style Guide
- jQuery Core Style Guidelines
- Principles of Writing Consistent, Idiomatic JavaScript
- StandardJS
Other Styles
- Naming this in nested functions - Christian Johansen
- Conditional Callbacks - Ross Allen
- Popular JavaScript Coding Conventions on GitHub - JeongHoon Byun
- Multiple var statements in JavaScript, not superfluous - Ben Alman
Further Reading
- Understanding JavaScript Closures - Angus Croll
- Basic JavaScript for the impatient programmer - Dr. Axel Rauschmayer
- You Might Not Need jQuery - Zack Bloom & Adam Schwartz
- ES6 Features - Luke Hoban
- Frontend Guidelines - Benjamin De Cock
Books
- JavaScript: The Good Parts - Douglas Crockford
- JavaScript Patterns - Stoyan Stefanov
- Pro JavaScript Design Patterns - Ross Harmes and Dustin Diaz
- High Performance Web Sites: Essential Knowledge for Front-End Engineers - Steve Souders
- Maintainable JavaScript - Nicholas C. Zakas
- JavaScript Web Applications - Alex MacCaw
- Pro JavaScript Techniques - John Resig
- Smashing Node.js: JavaScript Everywhere - Guillermo Rauch
- Secrets of the JavaScript Ninja - John Resig and Bear Bibeault
- Human JavaScript - Henrik Joreteg
- Superhero.js - Kim Joar Bekkelund, Mads Mobæk, & Olav Bjorkoy
- JSBooks - Julien Bouquillon
- Third Party JavaScript - Ben Vinegar and Anton Kovalyov
- Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript - David Herman
- Eloquent JavaScript - Marijn Haverbeke
- You Don’t Know JS: ES6 & Beyond - Kyle Simpson
Blogs
- JavaScript Weekly
- JavaScript, JavaScript...
- Bocoup Weblog
- Adequately Good
- NCZOnline
- Perfection Kills
- Ben Alman
- Dmitry Baranovskiy
- nettuts
Podcasts
This is a list of organizations that are using this style guide. Send us a pull request and we'll add you to the list.
아래 목록은 이 스타일 가이드를 사용하고 있는 단체들입니다. 우리에게 풀 리퀘스트를 보내면 리스트에 추가해드리겠습니다.
- 123erfasst: 123erfasst/javascript
- 3blades: 3Blades
- 4Catalyzer: 4Catalyzer/javascript
- Aan Zee: AanZee/javascript
- Adult Swim: adult-swim/javascript
- Airbnb: airbnb/javascript
- AltSchool: AltSchool/javascript
- Apartmint: apartmint/javascript
- Ascribe: ascribe/javascript
- Avalara: avalara/javascript
- Avant: avantcredit/javascript
- Axept: axept/javascript
- BashPros: BashPros/javascript
- Billabong: billabong/javascript
- Bisk: bisk
- Bonhomme: bonhommeparis/javascript
- Brainshark: brainshark/javascript
- CaseNine: CaseNine/javascript
- Cerner: Cerner
- Chartboost: ChartBoost/javascript-style-guide
- ComparaOnline: comparaonline/javascript
- Compass Learning: compasslearning/javascript-style-guide
- DailyMotion: dailymotion/javascript
- DoSomething: DoSomething/eslint-config
- Digitpaint digitpaint/javascript
- Drupal: www.drupal.org
- Ecosia: ecosia/javascript
- Evernote: evernote/javascript-style-guide
- Evolution Gaming: evolution-gaming/javascript
- EvozonJs: evozonjs/javascript
- ExactTarget: ExactTarget/javascript
- Expensify Expensify/Style-Guide
- Flexberry: Flexberry/javascript-style-guide
- Gawker Media: gawkermedia
- General Electric: GeneralElectric/javascript
- Generation Tux: GenerationTux/javascript
- GoodData: gooddata/gdc-js-style
- Grooveshark: grooveshark/javascript
- Grupo-Abraxas: Grupo-Abraxas/javascript
- Honey: honeyscience/javascript
- How About We: howaboutwe/javascript
- Huballin: huballin
- HubSpot: HubSpot/javascript
- Hyper: hyperoslo/javascript-playbook
- InterCity Group: intercitygroup/javascript-style-guide
- Jam3: Jam3/Javascript-Code-Conventions
- JeopardyBot: kesne/jeopardy-bot
- JSSolutions: JSSolutions/javascript
- Kaplan Komputing: kaplankomputing/javascript
- KickorStick: kickorstick
- Kinetica Solutions: kinetica/javascript
- LEINWAND: LEINWAND/javascript
- Lonely Planet: lonelyplanet/javascript
- M2GEN: M2GEN/javascript
- Mighty Spring: mightyspring/javascript
- MinnPost: MinnPost/javascript
- MitocGroup: MitocGroup/javascript
- ModCloth: modcloth/javascript
- Money Advice Service: moneyadviceservice/javascript
- Muber: muber
- National Geographic: natgeo
- Nimbl3: nimbl3/javascript
- Nulogy: nulogy/javascript
- Orange Hill Development: orangehill/javascript
- Orion Health: orionhealth/javascript
- OutBoxSoft: OutBoxSoft/javascript
- Peerby: Peerby/javascript
- Qotto: Qotto/javascript-style-guide
- Razorfish: razorfish/javascript-style-guide
- reddit: reddit/styleguide/javascript
- React: facebook.github.io/react/contributing/how-to-contribute.html#style-guide
- REI: reidev/js-style-guide
- Ripple: ripple/javascript-style-guide
- Sainsbury's Supermarkets: jsainsburyplc
- SeekingAlpha: seekingalpha/javascript-style-guide
- Shutterfly: shutterfly/javascript
- Sourcetoad: sourcetoad/javascript
- Springload: springload
- StratoDem Analytics: stratodem/javascript
- SteelKiwi Development: steelkiwi/javascript
- StudentSphere: studentsphere/javascript
- SwoopApp: swoopapp/javascript
- SysGarage: sysgarage/javascript-style-guide
- Syzygy Warsaw: syzygypl/javascript
- Target: target/javascript
- TheLadders: TheLadders/javascript
- The Nerdery: thenerdery/javascript-standards
- T4R Technology: T4R-Technology/javascript
- VoxFeed: VoxFeed/javascript-style-guide
- WeBox Studio: weboxstudio/javascript
- Weggo: Weggo/javascript
- Zillow: zillow/javascript
- ZocDoc: ZocDoc/javascript
This style guide is also available in other languages:
이 스타일 가이드는 다른 언어로도 제공됩니다:
Brazilian Portuguese: armoucar/javascript-style-guide
Bulgarian: borislavvv/javascript
Catalan: fpmweb/javascript-style-guide
Chinese (Simplified): yuche/javascript
Chinese (Traditional): jigsawye/javascript
French: nmussy/javascript-style-guide
German: timofurrer/javascript-style-guide
Italian: sinkswim/javascript-style-guide
Japanese: mitsuruog/javascript-style-guide
Korean: ParkSB/javascript-style-guide
Russian: leonidlebedev/javascript-airbnb
Spanish: paolocarrasco/javascript-style-guide
Thai: lvarayut/javascript-style-guide
Turkish: eraycetinay/javascript
Ukrainian: ivanzusko/javascript
Vietnam: hngiang/javascript-style-guide
- Find us on gitter.
(The MIT License)
Copyright (c) 2012 Airbnb
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
We encourage you to fork this guide and change the rules to fit your team’s style guide. Below, you may list some amendments to the style guide. This allows you to periodically update your style guide without having to deal with merge conflicts.
우리는 당신이 이 가이드를 포크해서 당신의 팀에 알맞도록 고쳐 쓰기를 바랍니다. 아래에 스타일 가이드의 수정 사항을 나열하세요. 이렇게 하면 병합 충돌(marge conflicts)을 신경쓰지 않고 스타일 가이드를 정기적으로 업데이트 할 수 있습니다.