코틀린 커뮤니티에 속한 사람이라면 이러한 컨벤션을 최대한 지켜주는 것이 좋다. 이를 지키면 아래와 같은 장점이 있다.
- 어떤 프로젝트를 접해도 쉽게 이해할 수 있다.
- 외부 개발자도 프로젝트의 코드를 쉽게 이해할 수 있다.
- 다른 개발자도 코드의 작동 방식을 쉽게 추측할 수 있다.
- 코드를 병합하고, 프로젝트의 코드 일부를 다른 프로젝트로 이동하는것이 쉽다.
컨벤션을 지킬 때 도움이 되는 도구들
- Intellij Formatter(Predefined style/Kotlin style guide)
- ktlint
자주 위반되는 규칙 중 하나는 클래스와 함수의 형식이다.
// BAD
class FullName(val name: String, val surname: String)
// GOOD
class Person(
val id: Int = 0,
val name: String = "",
val surname: String = ""
)
함수도 파라미터를 많이 갖고 있고 길다면 아래와 같이 작성한다.
public fun <T> Iterable<T>.joinToString(
separator: CharSequence = ", ",
prefix: CharSequence = "",
// ...
)
아래와 같이 작성하는 것은 두가지 측면에서 문제가 될 수 있다.
Class Person(val id: Int = 0,
val name: String = "",
val surname: String = "")
- 모든 클래스의 아규먼트가 클래스 이름에 따라 다른 크기의 들여쓰기를 갖는다. 이 경우 클래스 이름 변경 시 모든 기본 생성자 파라미터의 들여쓰기가 변경된다.
- 클래스가 차지하는 공간의 너비가 너무 크다.
일부 팀이 다른 규칙을 사용하기로 결정할 수 있지만 프로젝트의 컨벤션은 반드시 지켜주는 것이 좋다.
Reference
- 이펙티브 코틀린 - 프로그래밍 인사이트, 마르친 모스칼라 지음, 윤인성 옮김
개인적인 기록을 위해 작성된 글이라 잘못된 내용이 있을 수 있습니다.
오류가 있다면 댓글을 남겨주세요.