[Kotlin] 1-3. 코딩 관례
코딩 관례
명명 규칙
- 이름은 낙타표기법을 사용(이름에 밑줄 사용X) ex) putName
- 타입은 대문자로 시작
- 메서드와 프로퍼티는 소문자로 시작
- 4개의 공백문자 들여쓰기 사용
- public함수는 코틀린 Doc에 보이도록 문서화
***
콜론
타입과 하위 타입을 구분하는 콜론에는 이전에 공백 넣기 / 콜론이 인스턴스와 타입을 구분하면 공백 넣지 않는다
interface Foo<out T : Any> : Bar {
fun foo(a: Int): T
}
람다
람다식 안에서 중괄호 주변에 공백을 사용하고 파라미터와 몸체를 구분하기 위해 화살표 앞뒤로 공백
list.filter { it < 10 }.map { element -> element * 2 }
짧고 중첩되지 않은 람다에서는 파라미터를 it사용 권장 / 파라미터 충접되면 명시적으로 선언 ***
클래스 헤더 포맷팅
인자 개수가 적은 클래스는 한 줄로 작성할 수 있다
class Person(id: Int, name: String)
긴 헤더를 가진 클래스는 주요 생성자의 각 인자를 별도 줄로 들여쓰기해서 포맷팅
괄호는 새 줄에 작성 / 상속을 사용하면 상위 클래스의 생성자 호출이나 구현한 인터페이스 목록을 괄호화 같은 줄에 위치
class Person(
id: Int,
name: String,
surname: String
) : Human(id, name) {
// ...
}
다중 인터페이스를 상속한 경우 상위 생성자 호출을 먼저 위치시키고 각 인터페이스를 다른 줄에 위치
class Person(
id: Int,
name: String,
surname: String
) : Human(id, name),
KotlinMaker {
// ...
}
생성자 파라미터는 보통의 들여쓰기 or 연속 들여쓰기(보통 두배) 사용
Unit
함수가 Unit을 리턴하면 리턴 타입 생략
fun foo() { // ": Unit"을 생략
...
}
함수 vs 프로퍼티
인자 없는 함수의 경우 읽기 전용 프로퍼티로 교체 가능
다음 경우 함수보다 프로퍼티 선호
- 익셉션을 발생하지 않음
- O(1) 복잡도
- 계산 비용이 작음
- 호출마다 같은 결과 리턴