코틀린 문서의 코딩 컨벤션을 보면 알 수 있는 거처럼 코틀린은 잘 정리된 코딩 컨벤션을 갖고 있다.
물론 이 컨벤션이 모든 프로젝트에 최적인 것은 아니어도 지키면 좋다.
- 어떤 프로젝트를 접해도 쉽게 이해 가능
- 다른 외부 개발자도 프로젝트 코드 이해 가능
- 다른 개발자도 코드 작동 방식 쉽게 추측 가능
- 코드 병합하고 한 프로젝트의 코드 일부를 다른 코드로 이동하는 것이 쉬움
그래서 코틀린 개발자라면 문서에 설명되어 있는 컨벤션에 익숙해져야한다.
이 컨벤션은 시간이 지나면 조금씩 변화할 수 있다. 이런 변화도 수용가능해야 한다.
컨벤션 지킬때 도움되는 2가지
1) 포매터 (인텔리 제이나 안드로이드 스튜디오 모두 제공): 공식 코딩 컨벤션 스타일에 맞춰 코드를 변경해준다.
2) ktlint: 많이 사용되는 코드를 분석하고 컨벤션 위반을 알려주는 린터
게다가 코틀린은 자바의 코딩 컨벤션을 잘 따르고 있다. 왜냐면 많은 코틀린 개발자가 이전엔 자바 개발자였기 때문이다.
그러나 그 중 클래스와 함수의 형식 규칙이 자주 위반되는데 파라미터를 한 줄씩 작성하는 방법이다.
class Person(
val id: Int = 0,
val name: String = "",
val surname: String = ""
) : Human(id, name) {
// code
}함수도 파라미터를 많이 갖고 있고 길다면 다음과 같다.
public fun <T> Iterable<T>.joinToString(
separator: CharSequence = ", ",
prefix: CharSequence = "",
postfix: CharSequence = "",
limit: Int = -1,
truncated: CharSequence = "...",
transform: ((T) -> CharSequence)? = null
) : String {
// code
}하지만 다음과 코드는 하지말자.
class Person(val id: Int = 0,
val name: String = "",
val surname: String = "") : Human(id, name) {
// code
}-
모든 클래스 아규먼트가 클래스 이름에 따라 다른 크기의 들여쓰기를 갖습니다. 이런 형태로 작성하면, 클래스 이름을 변경할 때 모든 기본 생성자 파라미터의 들여쓰기를 조정해야 한다.
-
클래스가 차지하는 공간의 너비가 너무 크다. 처음 class 키워드가 있는 줄도 너비가 너무 크고, 이름이 가장 긴 마지막 파라미터와 슈퍼클래스 지정이 함께 있는 줄도 너무 크다.
물론 팀에 따라 다른 규칙을 사용하기로 할 수도 있다. 실행에는 문제가 없지만.
프로젝트의 컨벤션은 반드시 지켜주는 것이 좋다.
프로젝트의 모든 코드는 여러 사람이 싸우는 느낌으로 작성되면 안 되며, 마치 한 사람이 작성한 것처럼 작성되어야 한다.
많은 개발자가 코딩 컨벤션을 지키지 않지만 굉장히 중요하다
가독성과 관련된 어떤 책을 보아도 이 내용을 강조할 것이다.
정적 검사기를 활용해서 프로젝트의 코딩 컨벤션 일관성을 유지하길 바란다. 코딩 컨벤션을 준수하면 우리 모두에게 좋다!
