Kotlin + Spring 프로젝트에 ktlint 도입하기

Lint란?

코드 컨벤션이 문서로만 되어 있으면 과연 잘 지켜질까요? 아마 잘 지켜지지 않을 것입니다. 빼먹는 경우도 많을 것이고, 규칙을 알고도 잘 못 사용하는 상황이 생길 것입니다.

이때 코드 컨벤션, 코드의 오류나 버그를 지속적으로 확인하고, 미리 알려주는 도구가 Lint입니다.

 

ktlint vs detekt

코틀린에서 가장 흔히 쓰이는 린트에는 ktlint, detekt 두 가지가 있습니다.

 

ktlint는 Kotlin의 공식 가이드의 규칙을 포함하여 코드 스타일을 검사하고, 맞춰주는 도구입니다.

detekt는 코드포맷팅보다는 코드 복잡성, code smell 탐색과 같은 코드 분석에 초점을 둔 도구입니다.

 

ktlint는 선택한 이유

코드 컨벤션 유지와 코틀린 공식 코드 컨벤션에 초점을 맞춘 ktlint가 이번 프로젝트에 적합하다고 생각했기 때문에 ktlint를 도입하게 되었습니다!

 

두 린트는 서로 보완적인 역할을 하므로 두 린트의 기능이 다 필요하다면 둘 다 적용하여 코드 품질을 향상할 수 있습니다.

 

ktlint 도입

ktlint를 직접 설치하는 방법도 있지만, 협업하는 프로젝트이기 때문에 다른 개발자분과 환경을 맞추기 위해 의존성을 추가하는 방법을 선택했습니다.

 

gradle 추가

plugins {
      id("org.jlleitschuh.gradle.ktlint") version "<current_version>"
}

 

editorconfig 파일 추가

editorconfig은 IDE 관계없이 일정한 코드 스타일을 유지하기 위한 설정 파일입니다. ktlint는 기본적으로 코틀린 공식 코드 컨벤션을 따릅니다. 그럼에도 불구하고 editorconfig를 만든 이유는 다음과 같습니다.

 

1. ktlint 버전에 따라 코드 컨벤션 룰이 달라질 수 있음
2. 파일로 정의했기 때문에 코드 컨벤션에 대한 문서 역할을 함

root = true
[{*.kt,*.kts}]
ktlint_code_style = INTELLIJ_IDEA
max_line_length = 120
insert_final_newline = true

 

editorconfig 상세 설명

root = true
editorconfig 파일의 위치가 .editorconfig 존재하는 최상위 디렉터리임을 의미합니다. editorconfig 파일이 위치한 디렉터리와 그 하위 디렉터리에서는 다른 editorconfig 파일을 찾지 않고 이 파일의 설정을 사용합니다.

 

insert_final_newline = true
파일 끝에 줄을 추가합니다.

 

max_line_length = 120
한 줄의 최대 길이를 120자로 제한합니다.

 

ktlint 실행

 

./gradlew ktlintCheck

코드의 스타일을 검사하고, 규칙에 어긋난 코드가 있으면 오류가 발생합니다.

 

./gradlew ktlintFormat

코드의 스타일을 검사하고, 규칙에 어긋난 코드가 있으면 자동으로 수정합니다.

 

git hook을 사용해 커밋하기 전에 ktlintCheck를 통해 오류를 검출할 수 있습니다.

 

Ktlint, Github Action 연동

Github Action과 연동해 push, pull request와 같은 이벤트 발생 시 Ktlint를 실행해 코드를 검사할 수 있습니다.

name: Lint

on: [push, pull_request]

jobs:
    ktlint: # job 이름
        runs-on: ubuntu-latest # 실행환경을 우분투로 설정

        steps:
        - uses: actions/checkout@v3 # 내가 커밋한 브랜치로 체크아웃

        - name: ktlint
          uses: ScaCap/action-ktlint@master # ktlint 실행
          with:
              github_token: ${{ secrets.github_token }}
              reporter: github-pr-check # github-pr-check,  github-pr-review 두 가지 방식이 존재

 

 

github repository -> setting -> Branches에서 job 이름을 명시해 주면

 

ktlint 오류 발생 시 merge를 막을 수 있습니다.

 

결과물

github-pr-check 방식을 사용하면 ktlint 오류 발생 시 친절하게 알려줍니다.

 

마무리

협업을 할 때 코드의 일관성과 품질을 유지하는 게 중요한 것 같습니다. 코드 컨벤션을 지키면, 코드의 이해도를 높이고, 가독성이 향상되어 유지보수에 드는 비용을 줄일 수 있습니다. 개발 언어에 맞는 린트를 프로젝트에 적용해 코드의 일관성과 품질을 유지해 보면 좋을 것 같습니다! 

 

 

도움받은 글 🙇🙇🙇

https://pinterest.github.io/ktlint/1.0.0/rules/configuration-ktlint/

https://melonicedlatte.com/2022/06/11/235800.html
https://blog.benelog.net/ktlint.html
https://sungbin.land/ktlint-detekt-%EC%9C%BC%EB%A1%9C-%EC%BD%94%EB%93%9C-%ED%80%84%EB%A6%AC%ED%8B%B0-%ED%96%A5%EC%83%81%EC%8B%9C%ED%82%A4%EA%B8%B0-a085c7eba2cd
https://msyu1207.tistory.com/entry/%EA%B9%94%EB%81%94%ED%95%9C-%ED%8F%AC%EB%A7%B7%ED%8C%85%EC%9D%84-%EC%9C%84%ED%95%9C-ktlint-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-feat-kotlin#toc-%F0%9F%9A%80%20ktlint%20with%20gitAction