Write idiomatic Kotlin + Compose UI code with efficiency patterns

Gives idiomatic-efficiency guidelines for Kotlin and Jetpack Compose across seven areas: collections and data transformation, null safety, functions and lambdas, classes and objects, coroutines and Flow, Compose UI, and Kotlin-specific anti-patterns. Each area pairs a verbose or non-idiomatic pattern directly against the preferred Kotlin equivalent.

Use this skill when a task matches language-specific super-code guidelines for Kotlin - reviewing, writing, or refactoring Kotlin or Compose code toward idiomatic style. These are language-specific guidelines only and do not cover overall architectural decisions, and over-compression can reduce readability, so judgment should still be applied rather than mechanically collapsing every pattern regardless of context.

Collections favor scope functions and standard-library transforms over imperative loops: a manual filter-and-uppercase loop becomes a filter chained into a map, a manual grouping loop becomes groupBy, and a manual running-total loop becomes sumOf, alongside preferring associate, associateBy, partition, flatMap, and zip over hand-rolled equivalents:

val result = items.filter { it.isActive }.map { it.name.uppercase() }
val map = items.groupBy { it.category }
val total = orders.sumOf { it.amount }

Null safety favors the Elvis operator over an explicit null-check-then-assign, a safe call chained into let over a double null check, and an explicit requireNotNull contract or an early return over an unguarded double-bang assertion - the reasoning throughout is to push the non-null guarantee to the boundary where a value first enters a function, rather than scattering defensive checks and force-unwraps deep inside the logic where a missed one silently crashes at runtime. Functions favor a single-expression function body over an unnecessary block-and-return, dropping an unused lambda parameter that adds noise without adding meaning, and using apply to configure a builder object across several statements instead of repeating the receiver name on every line. Scope functions generally, meaning let, run, apply, also, and with, are preferred over repeated receiver references, but capped deliberately at no more than two levels of nesting, since stacking scope functions past that point trades a small amount of verbosity for a real readability cost that outweighs the savings.

Classes and objects favor a data class over a hand-written mutable class for immutable data, since a data class gives free equality, hashing, and copy semantics that a hand-rolled mutable class doesn't; a private top-level constant over a companion object that exists only to hold one value, since the companion object adds an extra allocation and lookup indirection for no real benefit when nothing else lives in it; and putting display logic directly on an enum's own constructor rather than a separate when statement that has to be kept in sync by hand in two different places whenever a new variant is added. Sealed classes or interfaces are preferred over a plain enum whenever the variants actually need to carry different data alongside them, since an enum's constructor is shared identically across every variant. Coroutines and Flow favor a plain suspend function call over an unnecessary async/await pair when the result is consumed immediately afterward, since the async wrapper adds concurrency overhead that buys nothing if nothing else runs in parallel with it; consumeEach or collect over a manual receive loop that has to hand-manage its own termination condition; and an atomic update block for StateFlow mutation over manually reassigning the backing value property in many separate call sites, which is both more verbose and more prone to a lost update under concurrent access. Coroutines should never be launched from a constructor or an init block, since that ties the coroutine's lifecycle to object construction rather than to an explicit, cancellable scope, and GlobalScope should never be used for the same underlying reason: it has no lifecycle to cancel against. Compose UI favors skipping remember for cheap derived state and reserving it specifically for computation that's genuinely expensive or that allocates a new object, since remember itself has a real cost that isn't free; passing only the specific field a composable actually needs rather than an entire state object, which improves both parameter stability and how narrowly a recomposition can be scoped; remembering a click-handler lambda rather than letting a fresh lambda instance be created on every single recomposition; and flattening a Column or Row that's nested purely to group children with no layout purpose of its own. Compose also calls for LazyColumn or LazyRow specifically for lists of unknown or large size, and warns against ever nesting a LazyColumn inside a Column with unbounded height, since that defeats the whole point of lazy layout. A dedicated anti-pattern table covers a further set of smaller, more mechanical Kotlin-specific issues: comparing a boolean value to true explicitly instead of just using the boolean directly, a double-bang assertion used right after a null check instead of the Elvis operator, calling toMutableList on an empty list literal instead of the direct mutableListOf constructor, a single-branch when-with-else used where a plain if/else reads more clearly, a redundant toString call on a value that's already a string, an explicitly written return type of Unit that the compiler already infers on its own, a manual object-expression implementation of a functional interface like Runnable instead of the shorter SAM-conversion form, the JvmStatic annotation applied in pure Kotlin code where it serves no purpose outside genuine Java interop, and wrapping every function body in its own logging try/catch instead of handling errors once at a shared boundary.

Kotlin and Jetpack Compose developers who want a fast before-and-after reference for idiomatic style across collections, null handling, functions, classes, coroutines, and Compose UI, rather than re-deriving each convention from scratch during review.