Javascript Style Guide 와 ESLint에 대한 이해

Javascript Style Guide

 

 

 

1. 가독성은 좋은 코드의 조건 중 하나

공백만으로도 가독성이 달라질 수 있다.

 

  개발에서의 가독성은 사람이 읽기 쉬운 코드를 작성하는 것을 의미합니다. 우리는 왜 가독성이 좋은 코드를 작성해야 할까요? "여러 개발자가 함께 일하기 때문이다"와 같은 표면적 이유들을 넘어 그 본질적 목표는 생산성의 향상에 있습니다.

 

  경제적인 관점에서, 기업은 투입되는 비용을 최소화하여 최대의 효율로 이윤을 내는 것이 굉장히 중요합니다. 투입되는 비용에는 개발 비용 즉, 개발에 투입되는 시간과 노력 등이 포함될 것이고, 가독성이 좋은 코드는 개발자들이 빠르고 쉽게 코드를 읽을 수 있어 코드를 이해하는데 필요한 시간을 줄일 수 있다는 장점이 있기 때문에 가독성이 곧 좋은 코드의 조건 중 하나가 될 수 있는 것이죠.

 

물론, 개발 대상이 되는 소프트웨어의 특성에 따라 좋은 코드의 우선 순위는 다를 수 있습니다. 예를 들어, 빠른 속도가 중요한 게임 개발에서는 좋은 성능이 가독성보다는 더 중요한 지표가 될 것입니다.

 

 

그럼 어떻게 가독성이 좋은 코드를 작성할 수 있을까요?

 

 

2. Coding Style Guide

객체의 key에 따옴표를 사용하자 vs 사용하지 말자

   같은 역할을 하는 코드를 작성하더라도, 들여쓰기나 변수 이름, 선언 위치 등 기능과는 상관 없는 부분에서 개발자마다 서로 다른 스타일로 작성한다는 사실을 우리의 선배 개발자들은 몸소 경험하며 깨달았습니다. 심지어 따옴표 vs 쌍따옴표의 구분도 필요합니다.  그리고 그런 불편함을 해결할 방편으로 Coding Style Guide를 만들었고, 현재의 우리는 그러한 코드 작성 규칙들을 Lint(또는 Linter)라는 도구를 통해 상당히 편리한 방법으로 검열할 수 있게 되었습니다.

 

 

---

3. Linter

 

Javascript 정적 분석 도구들

 

  Linter는 소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류, 의심스러운 구조체에 표시를 달아놓기 위한 도구입니다. Javascript 정적 분석 도구(Linter)는 JSLint, JS Hint, ESlint 등이 있습니다. JSLint는 2002년에 등장하여 역사가 깊고, JSHint는 JSLint의 규칙이 너무 엄격해서 보다 세팅이 유연하게 나온 도구입니다.  ESLint는 JSHint에 기여하던 Nicholas C. Zakas가 JSHint의 단점을 보완하여 만든 Linter이며, 현재 많은 개발자들이 ESLint를 주로 사용하고 있습니다. 본 포스팅에서도 ESLint를 사용하겠습니다.

 

 

---

 

4. ESLint

[설치 방법]

Getting Started with ESLint

1. npm으로 eslint를 설치합니다.

npm install eslint --save-dev

# or

yarn add eslint --dev

2. 설정을 위해 configuration file 생성합니다.

// package.json 파일이 존재하지 않다면, npm init or yarn init을 통해 package.json을 생성해야 한다.

$ npx eslint --init

# or

$ yarn run eslint --init

3. 생성된 configuration file(.eslintrc.{js,yml,json}) 에서 lint에 적용할 규칙들을 설정할 수 있습니다.

{
    "rules": {
        "semi": ["error", "always"],
        "quotes": ["error", "double"]
    }
}

+ example

module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  parser: 'babel-eslint',
  parserOptions: {
    //ECMAScript의 언어 확장 기능
    ecmaFeatures: {
      jsx: true,
    },
    //사용할 ECMAScript 버전
    ecmaVersion: 12,
    //parser의 export 형태
    sourceType: 'module',
  },
  //추가할 플러그인 ex)eslint-plugin-react에서 'react'만 입력
  plugins: ['react'],
  //추가한 플러그인에서 사용할 규칙. 역순으로 우선
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:prettier/recommended',
    'airbnb',
    'prettier',
  ],
  settings: {
    react: {
      version: 'detect',
    },
  },
  //프로젝트에서 사용하는 규칙. 0 : off, 1 : warn, 2 : error
  rules: {
    'react/jsx-filename-extension': 0,
    'react/jsx-one-expression-per-line': 0,
    'linebreak-style': 0,
    'import/no-unresolved': 0,
    'import/no-extraneous-dependencies': 0,
    'import/prefer-default-export': 0,
    'implicit-arrow-linebreak': 0,
    'operator-linebreak': 0,
    'comma-dangle': 0,
    'object-curly-newline': 0,
    'import/no-duplicates': 0,
    'no-param-reassign': 0,
    'no-return-assign': 0,
  },
};

rules: {...}를 통해 세부적인 규칙들의 사용 여부를 수정할 수 있습니다.
- "off" 또는 0 : 규칙을 사용하지 않음
- "warn" 또는 1 : 규칙을 경고로 사용
- "error" 또는 2 : 규칙을 오류로 사용

[Configuring ESLint 공식 문서 바로가기]

Configuring ESLint

 

 

ESLint 규칙(Rule) 설정

  - [ESLint rules 바로가기]

 

Rule 예시 살펴보기

  no-unused-vars : 선언된 변수가 사용되지 않았을 경우를 체크

 

no-unused-vars 라는 규칙에 대한 설명

 

규칙에 위배되는 incorrect 예시 & 규칙에 위배되지 않는 correct 예시

 

no-unused-vars 규칙에 위배될 경우, 마우스 커서를 올리면 message를 볼 수 있습니다.

no-unused-vars 규칙의 경우, 선언된 변수나 정의된 함수, 함수의 파라미터가 사용되지 않았을 때 경고 혹은 에러를 표시합니다. 

 

 

eslint-plugin-*  패키지

  plugin의 사전적 의미는 추가 기능을 위한 컴퓨터 프로그램 모듈 또는 장치라는 뜻인데, lint에서는 추가할 수 있는 룰의 집합 즉, rule의 모음이라고 생각하시면 됩니다. 필요한 규칙들을 묶어서 사용하기 위해 .eslintrc 파일을 eslint-plugin-* 와 같은 이름으로 모듈화해서 패키지로 사용할 수 있습니다. 

 

eslint-config-*  패키지

  eslint-config-* 는 여러 plugin과 rule들의 모음입니다. 프로젝트를 진행할 때, Coding Style Guide는 유명 회사들의 가이드를 따르기도 하는데, 대중적으로는 airbnb사의 eslint-config-airbnb이나 google사의 eslint-config-google가 있습니다. 해당 패키지를 통해 eslint 규칙의 틀을 구성하고, 너무 엄격하다고 판단되어 사용하고 싶지 않은 규칙들은 해당 rule의 이름을 찾아서 off하는 방식으로 eslint를 설정하기도 합니다.

 

Airbnb의 Javascript Style Guide를 확인할 수 있는 Github

 

 

---

ESLint 사용 시, 문제점

  ESLint의 규칙은 보통 개발을 시작하기 전 개발 환경 세팅 과정에 포함됩니다. 가독성의 향상이라는 명확한 목적이 있기 때문에 lint 규칙들을 잘 설정해 놓는다면, 코드 스타일과 관련한 불필요한 소통이 상당히 줄고, 코드의 품질에만 집중할 수 있을 것입니다. 다만, ESLint의 규칙들은 IDE 상에서 에러나 경고 문구를 보여주기는 하지만, 코드 동작에 직접적인 에러를 발생시키지는 못합니다. 이는 ESLint의 에러를 무시한 채 개발을 할 수 있다는 것을 의미하고, ESLint만으로는 작성된 코드가 ESLint의 규칙을 모두 지켰는지 보장할 수 없다는 것을 의미합니다. 그리고 프로젝트의 크기가 커질수록 프로그램 전체에 lint를 실행하는 시간이 길어진다는 문제도 있습니다.

 

해결 방법

  다행히 위 문제들을 보완할 수 있는 도구들도 함께 등장했습니다. 바로 husky와 lint-staged 입니다. 먼저, husky는 정적 분석 자동화 즉, 개발자가 직접 lint를 실행하여 분석하는 것이 아니라, git commit, git push 등이 실행되었을 때, git hook을 사용하여 lint를 자동으로 실행시켜주는 도구입니다. husky를 설정해놓으면, lint 실행을 잊은 채 commit을 해도 스타일 규칙을 체크할 수 있습니다.

 

  lint-staged는 전체 파일에 lint를 실행하는 것보다 수정한 부분 즉, commit하기 전인 git staged된 부분만 lint를 실행할 수 있도록 지원하는 도구입니다. lint-staged를 사용하면, 수정하지 않은 부분에서의 불필요한 lint 체크를 하지 않아 시간을 절약할 수 있습니다.

 

 

---

마무리

  Linter는 필수라고 할만큼 개발 프로젝트에 중요한 역할을 합니다. 설정하는 방법을 익히는 것보다는 여러 규칙들 중 나에게 맞는 규칙이 무엇이고, 어떤 규칙들이 불필요하다고 생각되는지, 경험과 rule 문서를 통해 알아가는 과정이 필요하다고 생각하며, 본인이 자주 사용하는 규칙들은 github repository 등에 저장을 해놓는 것이 이후 다른 프로젝트를 진행할 때 빠르게 설정할 수 있는 하나의 방법이 될 것입니다.

 

  추가로, 가독성의 향상을 위해 코딩 스타일 가이드를 활용한다고 하지만, 가독성이 좋은 코드를 작성하는 것은 단순히 스타일 가이드를 지킨다고 해결되는 문제는 아니라고 생각합니다. 변수의 이름을 결정하는 것이나 함수를 나누는 방법 등 Linter로 검출할 수 없는 모호한 부분들이 여전히 많이 존재합니다. 기업에서 사용하는 코딩 컨벤션에 대한 보다 자세한 내용은 [TOUST UI의 코딩 컨벤션]을 참고하시기 바랍니다.

 

 

 

 

---

[참고자료]

코딩컨벤션

 

Getting Started with ESLint