[Node.js] 3. 코드 스타일

3.1 ESLint를 사용하라

- ESLint는 발생 가능한 코드 에러를 체크하고 껄끄러운 간격 문제를 식별하는 것부터 프로그래머가 분별없이 에러를 던지는 것과 같은 코드의 심각한 안티 패턴을 감지하여 코드 스타일을 바꾸는 것에 대한 사실상의 표준이다.

- ESLint도 자동으로 코드스타일을 고칠 수 있지만 prettier와 beautify같은 수정 부분의 포맷을 맞춰주는 강력한 툴이 있고 ESLint와 함께 작동된다.

-> 그렇게 하지 않을 경우: 프로그래머가 쓸데없이 간격과 각 줄의 길이 문제에 집중하고 프로젝트의 코드스타일에 대해 과도하게 생각하느라 시간을 낭비하게 된다.

 

3.2 Node.js에 특화된 플러그인들

- vanila JS만 지원하는 ESLint의 표준 규칙 위에 eslint-plugin-node, eslint-plugin-mocha, eslint-plugin-node-security와 같은 Node에 특화된 플러그인을 같이 사용하라.

-> 그렇게 하지 않을 경우: 많은 결함이 있는 Node.js 코드 패턴들이 안중에서 벗어날 수 있다. 예를 들어 프로그래머는 변수로 된 파일 경로를 이용해 require로 파일을 가져올 수 있다. 이것은 공격자들이 어떤 JS script도 실행시킬 수 있게 한다. Node.js linter는 그러한 패턴을 감지하고 미리 알려준다.

 

3.3 코드 블록의 중괄호를 같은 줄에서 시작하라

// 좋은 예
function someFunction() {
  // 코드 블록
}

// 나쁜 예
function someFunction()
{
  // 코드 블록
}

3.4 문장을 제대로 분리해라

- ESLint를 써서 제대로 문장을 끝내고 있는지 경각심을 불러일으켜라. Prettier or Standardjs는 자동으로 이 문제를 해결해준다.

-> 그렇게 하지 않을 경우: 이전 섹션에서 본 것처럼 자바스크립트의 인터프리터는 세미콜론이 없으면 자동으로 문장의 끝에 세미콜론을 붙이거나, 문장이 끝났어야 함에도 끝났다고 인지하지 못하여 의도되지 않은 결과를 야기할 수 있다.

// 좋은 예
function doThing() {
    // ...
}

doThing()

// 좋은 예

const items = [1, 2, 3]
items.forEach(console.log)

// 나쁜 예 — 예외 발생
const m = new Map()
const a = [1,2,3]
[...m.values()].forEach(console.log)
> [...m.values()].forEach(console.log)
>  ^^^
> SyntaxError: Unexpected token ...

// 나쁜 예 — 예외 발생
const count = 2 // 2()를 호출하려 하지만, 2는 함수가 아니다
(function doSomething() {
  // 이쁜짓
}())
// immediate invoked function 전에 세미콜론을 놓던나, const 정의 후에 놓거나, 익명함수의 반환값을 변수에 저장하던가, 아니면 아예 IIFE를 쓰지 마라

3.5 함수에 이름을 붙여라

- 클로저와 콜백을 포함한 모든 함수에 이름을 붙여라. 익명함수를 피해라. 이것은 노드 앱을 프로파일링할 때 특히 유용하고 모든 함수를 명명하는 것은 메모리 스냅샷을 확인할 때 보고있는 것이 무엇인지 쉽게 이해할 수 있도록 해준다.

-> 그렇게 하지 않을 경우: 익명함수에서 메모리 소비가 많다는 것을 확인했을 때 코어 덤프를 이용해 프로덕션 문제를 디버깅하는 것이 어려울 수 있다.

 

3.6 변수, 상수, 함수, 클래스의 명명규칙

- 상수와 변수 함수를 명명할 때는 lowerCamelCase를 사용하고 클래스를 명명할 UpperCamelCase(첫 글자 대문자)를 사용하라. 이것은 일반 변수/함수와 인스턴스로 만들어야 하는 클래스를 구분하는데 도움을 줄 것이다. 

// 클래스명은 UpperCamelCase 사용
class SomeClassExample {}

// 상수명은 const 키워드와 lowerCamelCase 사용
const config = {
  key: "value",
};

// 변수와 함수 이름은 lowerCamelCase 사용
let someVariableExample = "value";
function doSomething() {}

3.7 let보다는 const를 사용하라. var는 개나줘라

- const는 변수에 한 번 값이 할당되면 다시 할당할 수 없다는 것을 의미한다. -> 같은 변수를 다른 용도로 사용하는 것을 방지하고 코드를 더 깔끔하게 만드는데 도움을 준다. for 루프처럼 변수가 재할당 되어야 할 필요가 있으면 let을 사용하여 선언하라. var는 블록범위가 아니라 함수범위이며 이제 대신할 수 있는 const와 let이 있으므로 ES6에서는 사용하면 안된다.

-> 그렇게 하지 않을 경우: 자주 변경되는 변수를 따라가려면 디버깅이 훨씬 더 번거로워진다.

 

3.8 require는 맨 처음에 오게하고 함수 안에서의 사용은 피하라

- 모듈을 각 파일의 시작이나 모든 함수의 앞부분 혹은 밖에서 require하라. 이는 파일의 의존성을 맨 위에서 쉽고 빠르게 구분할 수 있게 해줄 뿐만 아니라 여러 잠재적인 문제를 피하게 해준다.

-> 그렇게 하지 않을 경우: require는 Node.js에서 동기로 실행된다. 함수 안에서 호출되면 다른 요청들을 더 중요한 시간에 처리되지 못하도록 막을 수 있다. 또한 requiree된 모듈이나 그것의 의존 모듈이 에러를 뱉거나 서버를 다운시키면, 함수 안에서 그 모듈이 require된 것이 아닌지 가능한 아주 빠르게 찾아야 할 것이다.

 

3.9 파일 대신 폴더를 require 해라

- 폴더 안에서 모듈/라이브러리를 개발할 때, 모든 소비자가 내부를 노출하는 index.js 파일을 거치도록 해라. 이것은 모듈의 '인터페이스' 역할을 하며 계약을 위반하지 않으면서 미래의 변경사항에 대해 유연하게 대처하도록 해준다.

// 좋은 예
module.exports.SMSProvider = require("./SMSProvider");
module.exports.SMSNumberResolver = require("./SMSNumberResolver");

// 나쁜 예
module.exports.SMSProvider = require("./SMSProvider/SMSProvider.js");
module.exports.SMSNumberResolver = require("./SMSNumberResolver/SMSNumberResolver.js");

3.10 === 연산자를 사용하라

- 약하고 추상적인 같음연산자 == 보다 엄격한 항등연산자 ===를 선호한다. ==는 두 변수를 공용 타입으로 변환한 후에 비교한다. ===에는 타입 변환이 없고 두 변수가 같으려면 타입도 같아야 한다.

-> 그렇게 하지 않을 경우: ==으로 비교하는 경우 같지 않은 변수가 true로 반환될 수 있다.

"" == "0"; // false
0 == ""; // true
0 == "0"; // true

false == "false"; // false
false == "0"; // true

false == undefined; // false
false == null; // false
null == undefined; // true

" \t\r\n " == 0; // true

3.11 async-await을 사용하고 콜백을 피해라

- async-await 이것은 콜백과 promise를 대체하여 비동기 코드를 다루는 새로운 방법이다. async-await은 비차단적이고 비동기 코드를 동기 코드처럼 보이게 만든다. 

-> 그렇게 하지 않을 경우: 콜백 스타일로 비동기 에러를 처리하는 것은 아마도 지옥으로 가는 가장 빠른 방법일 것이다. 이런 스타일은 에러를 전부 확인하게 하고 어색한 코드 중첩을 다루게하며 코드 흐름을 추론하기 어렵게 만든다.

 

3.12 두꺼운 화살표(=>) 함수를 사용해라

- async-await을 사용하고 함수 인자를 사용하는 것을 피하는 것이 권장되지만 promise와 콜백을 받는 예전 API를 다룰 때는 화살표 함수가 코드 구조를 더 작게해주고 루트 함수의 어휘적 맥락을 유지시켜 준다.

-> 그렇게 하지 않을 경우: 긴 코드는 버그에 취약하고 읽기도 번거롭다.