이펙티브 코틀린 2장 - 가독성

---

아이템 11. 가독성을 목표로 설계하라

로버트 마틴의 클린 코드 ... "개발자가 코드 작성하는 데는 1분 걸리지만, 읽는 데는 10분이 걸린다."

가독성이란, 코드를 읽고 얼마나 빠르게 이해할 수 있는지를 의미한다.

// A
if (persion != null && person.isAdult) {
  view.showPerson(person)
} else {
  view.showError()
}

// B
person?.takeIf { it.isAdult }
  ?.let(view::showPerson)
  ?: view.showError()

A가 읽고 이해하기가 쉬운데, 기본적으로 '인지 부하'를 줄이는 방향으로 코드를 작성하라고 한다.

100% 공감이 되지는 않는다. 함수형 프로그래밍을 잘 익히고, 잘 사용한다면 충분히 읽고 이해하기 쉬우며, 책에서 말하는 '인지 부하' 측면에서도 오히려 더 줄일 수 있지 않을까..? 생각한다.

 

가독성은 '뇌가 프로그램의 작동 방식을 이해하는 과정'을 더 짧게 만드는 것

대표적으로 함수 추출, 추상화 등의 작업이 있을 것 같다.

students
    .filter { it.result >= 50 }
    .joinToString(separator = "\n") { "${it.name} ${it.surname}, ${it.result}" }
    .let(::print)


var obj = FileInputStream("/file.gz")
    .let(::BufferedInputStream)
    .let(::ZipInputStream)
    .let(::ObjectInputStream)
    .readObject() as SomeObject

 

let을 사용하기 좋은 2가지 예시는?

• 연산을 아규먼트 처리 후에 호출할 떄
• 데코레이터를 사용해 객체를 랩할때

---

아이템 12. 연산자 오버러드를 할 때는 의미에 맞게 사용하라

의미에 맞지 않게 사용한 예시 (팩토리얼 구현)

fun Int.factorial(): Int = (1..this).product()

fun Iterable<Int>.product(): Int = fold(1) { acc, i -> acc * i}

operator fun Int.not() = factorial()

fun main() {
    println(!6) // 720

    println(6.not()) // 720
}

위 구현 방식의 문제점?

• 함수 이름과 실제 동작이 일치하지 않는다.
• not은 논리 연산을 위한 것인데, 팩토리얼 계산에 사용되어 혼란을 줄 수 있다.

코틀린 연산자의 특징

• 모든 연산자는 함수의 별칭이다.
• 각 연산자의 의미는 일관되게 유지되어야 한다.

연산자의 의미가 명확하지 않은 경우,

tripledHello = 3 * { print("Hello") }

위 코드는 함수를 3번 반복하는 "새로운 함수 생성"을 의미하는지, 함수를 즉시 3번 호출하는 지 명확하지 않다.

 

위의 경우 infix 함수를 사용하여 의도를 명확히 할 수 있다.

infix fun Int.timesRepeated(operation: () -> Unit) = {
    repeat(this) { operation() }
}

fun main() {
    val tripledHello = 3 timesRepeated { print("Hello") }
}

 

Infix 함수를 사용하는 대표적인 예제 (Map)

val days = mapOf("Monday" to "월요일", "Tuesday" to "화요일")

---

아이템 13. Unit? 을 리턴하지 말라

채용 인터뷰 과정에서 필자의 친구는 “함수에서 Unit을 리턴한다면, 그 이유는 무엇일까요?” 라는 질문을 받았다.

 

Boolean이 true/false 를 갖는 것처럼, Unit?은 Unit, null이라는 값을 가질 수 있다.

fun keyIsCorrect(key: String): Boolean = key.length > 5
fun verifyKey(key: String): Unit? = if (key.length > 5) null else Unit

if (!keyIsCorrect(key)) return
verifyKey(key) ?: return

지금까지 여러 코드를 보면서 Unit?을 쉽게 읽을 수 있는 경우는 거의 보지 못했고, 오해를 불러 일으키기 쉽다.

기본적으로 Unit?을 리턴하거나, 이를 기반으로 연산하지 않는 것이 좋다.

 

Unit vs Void vs Nothing

• https://stackoverflow.com/questions/55953052/kotlin-void-vs-unit-vs-nothing

---

아이템 14. 변수 타입이 명확하지 않은 경우 확실하게 지정하라

코틀린은 개발자가 타입을 지정하지 않아도 타입을 지정해서 넣어 주는 굉장히 수준 높은 타입 추론 시스템을 갖추고 있다.

이는 개발 시간을 줄여줄 뿐만 아니라, 유형이 명확할 때 코드가 짧아져서 가독성 또한 향상된다.

하지만 유형이 명확하지 않을 때 남용하는 것은 좋지 않다.

// Bad
val data = getSomeData()

// Good
val data: UserData = getSomeData()

가독성을 위해 코드를 설계할 때는 사람에게 중요한 정보를 숨겨서는 안 된다.

 

요즘 대부분 IDE에서 타입을 보여주는 (Inlay Hints) 기능을 제공하기 때문에 대부분의 상황에서는 굳이 타입을 정의할 필요가 있을까? 하는 생각이긴 하다.
(GitHub와 같이 코드리뷰 할 때 웹사이트 상에서는 타입이 확인이 불가능해서 조금 불편한 점은 있었지만, 이러한 경우 제외..)

타입이 nullable이거나, 의도와는 다른 경우, 여러 연산이 포함되어 타입 추론이 힘든 경우 등 명확한 타입 정의가 필요한 경우에만 선언해도 충분하지 않을까 싶다.

---

아이템 15. 리시버를 명시적으로 참조하라

생략할 수 있는 경우에도 this를 명시적으로 사용하여 코드를 작성하는 경우가 있다.

또한 여러 개의 리시버가 있는 상황에서도 리시버를 명시적으로 적어 주는 것이 좋다.

// block: (T) -> R  일반적인 함수 정의
val block: (Int) -> Int = ...
block(3)

// block: T.() -> R  객체 T를 receiver 로 활용한 Lambda with receiver
val block: Int.() -> Int = ...
100.block(3)

 

리시버(Receiver): 객체 외부의 람다 코드 블록을 마치 해당 객체 내부에서 사용하는 것 처럼 작성할 수 있게 해주는 장치

block : T.() -> R

위 람다 블록은 객체 T를 receiver로 이용하여 객체 R을 반환한다.
위에서 객체 T를 리시버라 부르고, 리시버를 사용하는 람다를 Lambda with receiver 라고 부른다.

참고: https://jaeyeong951.medium.com/kotlin-lambda-with-receiver-5c2cccd8265a

---

아이템 16. 프로퍼티는 동작이 아니라 상태를 나타내야 한다

코틀린의 프로퍼티에는 많은 기능들이 존재한다.

var name: String? = null
    get() = field?.uppercase()
    set(value) {
        if (!value.isNullOrBlank()) {
            field = value
        }
    }

 

코틀린에서는 필드에 대한 접근자 메서드(getter, setter)를 자동으로 생성한다. 때문에 필드 대신 프로퍼티라는 용어를 사용하는데, 원할경우 접근자 메서드를 명시적으로 선언할 수도 있다.

 

Backing Field

backing field는 프로퍼티의 값을 저장하기 위한 필드이다.

 

backing field는 프로퍼티의 값을 저장하기 위한 필드다. 코틀린에서는 필드를 바로 선언할 수 없고 프로퍼티로 선언하면 기본적으로 backing field가 생성된다.

class KotlinProperty {
    var counter = 0
        set(value) {
            if (value >= 0) field = value
        }
}

// Java
public class KotlinProperty {
    private int counter = 0;

    public int getCounter() {
        return counter;
    }

    public void setCounter(int value) {
        if (value >= 0) {
            this.counter = value;
        }
    }
}

 

어떤 것을 프로퍼티로 해야 할지 판단할 수 있는 간단한 질문은, "이 프로퍼티를 함수로 정의할 경우 접두사로 get/set을 붙일 것인가? 만약 아니라면, 이를 프로퍼티로 만드는 것은 좋지 않다."

조금 더 구체적으로 프로퍼티 대신 함수를 사용하는 것이 좋은 경우,

• 연산 비용이 높거나 복잡도가 큰 경우
• 비즈니스 로직을 포함하는 경우
• 변환의 경우 (toString(), toInt())
• getter에서 프로퍼티의 상태 변경이 일어나야 하는 경우

---

아이템 17. 이름 있는 아규먼트를 사용하라 

val text = (1..10).joinToString("|")

 

위 코드에서 joinToString 함수의 아규먼트에 | 가 의미하는 바는, 해당 함수를 모른다면 이해하기 힘들 수 있다.

 

val text = (1..10).joinToString(separator = "|")

따라서 위 처럼 아규먼트를 명시적으로 사용하여 작성할 수 있다.

 

그렇다면, 위와 같은 이름 있는 아규먼트를 언제 사용해야 할까?

• default 아규먼트의 경우,
• 같은 타입의 파라미터가 많은 경우,
• 함수 타입의 파라미터 (함수 타입 파라미터는 마지막 위치에 배치하는 것이 좋다.)

대표적으로 위와 같은 경우 이름 있는 아규먼트를 사용하는 것이 좋겠다.

 

그렇다면, 이름 있는 아규먼트를 사용하면 무슨 장점을 가질까?

• 이름을 기반으로 값이 무엇을 나타내는지 알 수 있다.
• 파라미터 입력 순서와 상관 없으므로 안전하다.

이름 있는 아규먼트는 개발자가 코드를 읽을 때도 편리하게 활용되며, 코드의 안전성도 향상시킬 수 있다.

@kotlin.internal.InlineOnly
public inline fun repeat(times: Int, action: (Int) -> Unit) {
    contract { callsInPlace(action) }

    for (index in 0 until times) {
        action(index)
    }
}

// 사용 예시
fun main() {
    repeat(5) { index ->
        println("Hello! This is message #${index + 1}")
    }
}

 

만약 함수 타입의 파라미터가 마지막 위치가 아닌 경우, 아래 처럼 가독성이 좋지 않다.

@kotlin.internal.InlineOnly
public inline fun repeat(action: (Int) -> Unit, times: Int) {
    contract { callsInPlace(action) }

    for (index in 0 until times) {
        action(index)
    }
}


repeat(action = { println(it) }, times = 5)

---

아이템 18. 코딩 컨벤션을 지켜라

• IDE의 formatter 활용
• 정적 분석 도구 (ktlint, sonarqube 등) 활용

https://kotlinlang.org/docs/coding-conventions.html

Coding conventions | Kotlin