[Lint] ktlint 를 사용한 Coding Convention 맞추기

Coding Convention 을 쉽게 맞출 수 있는 Lint 에 대하여 공부를 진행하다가,

ktLint 라는 것이 있어서 확인해 보았는데, 적용 및 사용 방법이 간단하여 한번 사용해 보았다.

---

ktLint 란 무엇인가 ?

kotlin 환경의 프로젝트에서 사용이 가능한 오픈소스로,

Android Kotlin Style Guide 와 kotlin Coding Convention 규칙을 준수하는지 체크해준다.

나아가, 코딩 컨벤션을 준수하고 있지 않은 코드가 있으면 커밋을 못하게 막는 등의 작업을 제한시킬 수 있으며, 옵션에 따라 자동적으로 수정까지 해주기도 한다.

 

자동적으로 수정까지 해주는 옵션이 있기는 하지만, 필자가 여러가지 테스트해본 결과 자동으로 수정하도록 하는 경우에 정상적인 수정이 이루어지지 않는 경우가 보이기 때문에, 수정까지 하는 것 보다 컨벤션이 안맞는 부분을 찾는 도구로 사용하면 될 것으로 생각한다.

 

ktlint에서 제공하는 컨벤션 룰을 확인하려면, ktlint 의 github 를 참고하길 바란다.

https://ktlint.github.io/

ktlint

---

그렇다면 이제,

ktLint 를 사용해 보자.

 

ktlint 를 사용하기 위해서는 project 단위의 gradle 에서 작업을 진행해야 한다.

 

 

 

afterEvaluate 에 선언한 common.gradle 은 생략해야 한다. 필자가 예전에 gradle 공통화를 위해 작성해둔 코드이기 때문이다.

 

실제로 ktLint 를 사용하기 위해 선언한

TASK에 대하여 알아보자.

확인 가능한 2개의 task인 ktlint 와 ktlintFormat 이 추후 명령어로 사용할 부분이며, 만약, ktlinformat 을 사용하고 싶지 않다면 해당 task는 제거해도 상관 없는 부분이다.

 

또한, group 과 description 부분은 사용자가 마음대로 세팅해도 되는 부분이며,

ktlint 라는 task의 이름도 변경이 가능한데 이 때는 task에 선언한 이름만 변경하는 것이 아닌 ktlint 라고 작성되어있는 모든 부분을 함께 바꿔 주어야 한다.

 

args에 선언된 부분에서, "src/**/*.kt" 라고 선언한 부분은 ktlint 를 수행시킬 경로를 특정하는 것이다.

위와 같이 선언을 하게 되면 모든 코틀린 코드에 대하여 ktlint 를 수행시킨다는 의미가 된다.

반대로, !를 붙여서 검사 대상에서 제외 시킬 수도 있다.

예로들어, "!src/**/*Sample.kt" 라고 선언한다면, 모든 kt 파일 중 Sample로 끝나는 kt 파일을 제외하고 ktlint 를 수행시킨다는 의미가 된다.

 

코드를 천천히 읽어본 사람을 알겠지만, 2개의 task 에서의 차이점은

사용자가 마음대로 세팅해도 되는 group, description 을 제외하면 args 에서 "-F" 라는 옵션밖에 존재하지 않는다.

-F 라는 옵션을 붙이게 되면 ktlint 를 통해 코딩 컨벤션을 체크하게 되고, 일치하지 않는 부분을 자동으로 수정하겠다 는 옵션이다.

즉, ktlintFormat 을 호출하게 된다면 알아서 코딩 컨벤션이 틀린 부분을 수정까지 해준다는 의미이다.

 

위에 설명한 것들 외로, reporter 옵션을 추가/제거할 수 있다고는 하는데 필자는 기본적인 옵션만 사용하여 ktlint 를 사용해도 충분하다고 생각되었다.

---

gradle 에 설정이 끝났으니,

실제로 사용해볼 차례이다.

필자가 위에 설명을 하면서 명령어를 사용하여 ktlint 를 수행시킨다. 라는 말을 하였는데,

이것은 안드로이드 스튜디오 내부의 터미널에서 명령어를 사용함으로써 ktlint 를 실행시킬 수 있기 때문에 이렇게 말하였다.

 

그렇다면,

터미널에서 어떻게 사용해야 하는가?

공식 깃허브를 확인해보자.

 

 

터미널에 다음과 같이 입력을 하라고 한다.

 

안된다.

 

다른 블로그를 찾아보았다.

 

./gradlew ktlint
./gradlew ktlintFormat

 

형식으로 사용하란다.

 

안된다.

 

여기서 필자는 뭔가 설정이 추가적으로 필요한 것인지, 한참 찾아보았다.

하지만 그런 설정은 없었고, 아주 간단한 방법으로 사용이 가능했다.

 

gradlew ktlint
gradlew ktlintFormat

 

과 같이, 앞에 다른거 붙이지 말고 그대로 선언하여 사용하면 된다.

 

아무런 문제가 없다면, 이런식으로 동작하는 것을 확인할 수 있다.

 

터미널에 위의 함수를 실행시켰는데 정상적으로 동작하지 않는다면, gradlew 만 한번 실행시켜 정상적으로 구동하고있는지 확인한 후에 다시한번 시도해보면 될 것이다.

 

 

정상적으로 동작한다면,

이처럼 코딩 컨벤션에 일치하지 않는 코드들과, 어떤 부분을 수정해야 하는지 확인할 수 있다.

 

위의 수정할 코드가 있는 상태에서, gradlew ktlintFormat 을 수행시키면 정상적으로 수정이 되는 것을 확인할 수 있는데, 이 수정의 범위가 애매한 부분이 있다.

 

우선, 코딩 컨벤션 규칙에 import 시 와일드 카드를 사용하면 안된다고 되어있다.

하지만, 와일드 카드를 사용하여 import 하는 경우 ktlint 를 통해 발견은 되지만 ktlintFormat 을 통하여 자동 수정이 안되고 오류만 발생시키는 경우가 있었다.

또한, 다른 블로그를 찾아보니 이런 경우 외에도 정상적인 수정이 이루어지지 않는 경우가 있다고 하니 편하더라도 자동 수정은 참고용으로만 사용하는게 좋지 않을까 생각한다.

---

이것들 외에도,

자신만의 룰을 추가한다던지, git hook 을 사용하여 커밋 자체를 막는다던지의 작업도 추가가 가능한 것으로 보인다.

하지만, 그 기능에 대한 필요성을 아직 느끼지 못하였고,

rule 을 추가하는 것에 있어서는 난이도가 상당하다고 생각하였기 때문에 해당 작업까지는 추가하지 않았다.

 

ktlint 에서 rule 을 추가하여 사용하고 싶은 경우, 아래의 github에서 방법을 확인하길 바란다.

https://github.com/pinterest/ktlint#creating-a-ruleset

GitHub - pinterest/ktlint: An anti-bikeshedding Kotlin linter with built-in formatter

 

필자는 ktlint 을 적용하여 기본적인 것들 만 사용해 보았다.

상당히 간단하게 적용하여 사용할 수 있는 오픈 소스였지만, 가이드 대로 따라해도 제대로 적용이 되지 않아 생각보다 시간이 걸렸다.

 

기본적인 코딩 컨벤션을 맞추는 목적으로 사용한다면, 괜찮을 것으로 보이지만

rule 을 추가하여 코딩 컨벤션을 체크하는 등, 추가적인 옵션을 넣게 된다면 ktlint 보다 lint 를 사용하는게 더 진입 장벽이 낮지 않을까 생각한다.