1. Meaningful Names · Clean Code

[THEORY]

[PREDICT]

Read the code carefully before you run it.

prediction.kt

fun calc(a: Double, b: Double): Double {
    val d = a * b / 100.0
    return a - d
}

fun main() {
    // The caller meant: a 15 percent discount on a price of 200.0.
    println(calc(15.0, 200.0))
}

The caller meant a 15 percent discount on a price of 200.0. What does this print, and what in the code could have warned them?

[COMPREHENSION CHECK]

1. A pull request contains val activeUsers = users.filter { !it.isActive }. What is the most serious problem with this line?

filter creates a new list, so the name should say that the result is a copy The lambda should name its parameter instead of using it, because it hides what the element is Collection names should end in List so that readers see the type at a glance The name contradicts the filter, so readers will trust the name and treat inactive users as active

2. Which of these names is a problem?

sum for the running total in a four-line function it inside the one-line lambda orders.map { it.total } t as a private property that ten methods of a class read i as the index of a three-line for loop

3. Your team lead proposes prefixing every variable with its type, as in strName and iCount, so readers always see the type. What is the strongest objection?

Kotlin infers types, so a prefix could never match the declared type and would always be wrong The prefix is fine as long as the whole team applies it consistently, because consistency is what matters Typing the prefixes costs time, but with autocomplete the cost is negligible, so there is no real objection The IDE and the compiler already know the type, and the prefix silently becomes wrong when the type changes

4. The line val ok = customer.age >= 18 && customer.idVerified decides whether an order with age-restricted items may go through. Which rename follows the rule "name the purpose, not the mechanics"?

result canBuyAgeRestrictedItems ageAtLeast18AndIdVerified ageAndIdCheck

5. fun checkPassword(user: User, password: String): Boolean verifies the password and, when it matches, also starts a session for the user. What is the naming problem?

The name is too long: Kotlin style asks for short function names such as check Functions that return a Boolean must start with is or has, so the name should be isPasswordValid The name promises a plain check, but the call also changes state, so callers cannot predict it check is a reserved word in Kotlin, so a function name cannot start with it