skip to content

Scope functions can hurt readability when overused. What anti-patterns do you watch for, and what conventions keep chains clear?

level: seniorimportance: nice to knowfreq 30%

answer

  1. implicit this/it/return is the readability cost
  2. don't chain just to avoid a val
  3. if (x!=null) smart-casts; ?.let for mutable/chaining
  4. keep chains shallow; extract functions
  5. honor apply=config, also=side-effect

basics

~20 s

Avoid long stacked chains, using scope functions just to save a variable, mixing this and it confusingly, and using them only for null checks where an if or early return is clearer. Pick the one whose this/it/return matches your intent.

solid answer

~50 s

Common anti-patterns: (1) deep chains stacking let/apply/also/run that obscure data flow — a named intermediate val often reads better; (2) using let merely to avoid declaring a variable, adding indentation for no gain; (3) reaching for ?.let on a property when a smart-cast via if (x != null) or an early return is clearer (and let on a mutable property doesn't smart-cast cleanly across threads anyway); (4) mixing this- and it-based functions so the reader loses track of the context object; (5) using apply for side effects or also for configuration, breaking the intent convention. Conventions that help: choose by the two axes (does this/it read better; do I need the result or the object), keep chains shallow, name the parameter when it isn't obvious, and prefer explicit control flow over a scope function when the logic is conditional rather than a transform.

code

kotlin · 12 lines
kotlin
// Overused (implicit, hard to scan):
fun label(id: Int) = repo.find(id)
    ?.let { it.name }
    ?.also { println(it) }
    ?.let { it.uppercase() }

// Clearer intent with explicit flow:
fun label2(id: Int): String? {
    val user = repo.find(id) ?: return null
    println(user.name)
    return user.name.uppercase()
}

go deeper

for a junior

Recognizes that a very long chain is hard to read and a variable can help.

for a middle

Identifies gratuitous let and chooses explicit control flow vs ?.let appropriately.

for a senior

Articulates the implicit-context readability cost, the smart-cast nuance for mutable properties, and consistent-chain conventions.

for a principal

Sets team-wide style guidance (chain depth limits, apply/also intent rules) and balances DSL expressiveness against scannability in reviews.

## Why overuse hurts Scope functions are *implicit*: the context object and return value are encoded in the function name, not in the code you read. Stack several and the reader must mentally track, at each step, whether the object is `this` or `it` and whether the value is the result or the original object. Past a couple of links, a named variable is clearer. ## Anti-pattern 1 — gratuitous chains ```kotlin // Hard to follow: val x = repo.find(id) ?.let { it.copy(active = true) } ?.also { audit.log(it) } ?.run { repo.save(this) } ?.let { it.id } // Often clearer with a named step or two: val user = repo.find(id) ?: return null val activated = user.copy(active = true) audit.log(activated) val saved = repo.save(activated) return saved.id ``` ## Anti-pattern 2 — let just to avoid a variable `value.let { compute(it) }` is no better than `compute(value)`; the `let` adds a lambda and indentation for nothing. Use `let` when you genuinely want null-safe chaining or a renamed scope, not to dodge a `val`. ## Anti-pattern 3 — `?.let` where control flow is clearer For a local `val`, `if (x != null) { use(x) }` smart-casts `x` to non-null and reads as ordinary control flow. `x?.let { use(it) }` is fine for chaining but isn't automatically better. For a **mutable property** (`var` / from another module), `?.let` is actually a common idiom precisely because the property can't be smart-cast — but if the logic is conditional branching (`if/else`), explicit flow usually wins over nesting `let`/`run`. ## Anti-pattern 4 — mixing `this` and `it` opaquely Alternating receiver- and argument-based functions in one chain makes the context object jump between implicit `this` and named `it`. Keep a chain's mental model consistent or break it up. ## Anti-pattern 5 — breaking the intent convention `apply` for logging or `also` for property assignment compiles but defeats the signal each function carries (config vs side effect). Reviewers rely on these signals. ## Conventions that keep code clear - **Choose by the two axes**: receiver vs argument (does `this` or `it` read better?), and result vs original object (do you want the computed value or the same object?). Let intent pick the function. - **Keep chains shallow** — two or three links max; extract a named function otherwise. - **Name the lambda parameter** when `it` is non-obvious or nested (`also { order -> ... }`). - **Reserve `apply` for configuration, `also` for side effects.** - **Prefer explicit control flow** (`if`, early `return`) when the logic is conditional, not a linear transform. None of this is performance — all scope functions are `inline`. It's purely about communicating intent.

  • Is replacing scope functions with named vals a performance trade-off?
    No — scope functions are inline, so there's no allocation either way. The trade-off is purely readability/intent.
  • When is ?.let genuinely better than if (x != null)?
    When x is a mutable/external property that can't be smart-cast, or when you're mid-chain and want null-safe transformation without breaking the flow.

A scope-function chain is like a run-on sentence: a few clauses flow, but a paragraph of them needs to be broken into separate sentences (named vals).

saying these in an interview costs you the question

  • Claiming chaining scope functions is faster than plain code
  • Always preferring ?.let over an if even for local vals
  • Defending deeply nested chains as idiomatic
  • Saying named intermediate variables are non-idiomatic
  • Ignoring the apply/also intent convention

context

resolving links…