3. 코드 스타일

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(첫 글자 대문자)를 사용하라. 이것은 일반 변수/함수와 인스턴스로

from http://yunbo96.tistory.com/81 by ccl(A) rewrite - 2021-09-13 15:00:17