Control Flow

Kotlin has no a ? b : c. You use if/else directly, because if returns a value. Write val m = if (a > b) a else b. The if/else expression takes the place of the ternary.

A plain break only stops the loop directly around it (the innermost one). To stop an outer loop, you put a name (label) on that loop and write break@name.

A bare return inside a forEach lambda exits the whole surrounding function, not just the loop step. To skip only the current step you write return@forEach, which leaves the lambda and continues the loop.

If you use when to produce a value (like assigning it to a variable or returning it), it must handle every possible case. If you use when just to do an action and ignore its value, it does not have to cover everything.

when is Kotlin's replacement for switch. You list conditions and pick the first matching branch. It can be used as a value-producing expression or as a plain statement, and branches don't fall through.

1..10 counts 1 to 10 including both ends. until stops one before the end. downTo counts backwards. step changes how big each jump is. Mixing them wrong can make an empty range.

If you use the if's result (assign it, return it, pass it), you must include else so every path produces a value. If you ignore the result and just run side effects, else is optional.

break@outer quits the named outer loop completely. continue@outer skips the rest of the current inner work and jumps to the outer loop's next iteration. Both target the labeled loop, but one stops it, the other advances it.

Usually omit the else. Then if someone adds a new subtype later, the code stops compiling and points you to every when you must update. Adding an else hides those spots and lets bugs slip through.

is Type matches when the subject is that type; !is is the opposite. Inside an is branch Kotlin smart-casts the value to that type automatically, so you can call its members without an explicit cast.

while checks the condition before running the body, so it may run zero times. do-while runs the body once first, then checks. Use while when the number of steps isn't a simple count.

Use withIndex() in the for loop. It gives you a pair of (position, value) for each item, so you can read both at once without manually tracking a counter.

The type is the closest common type that fits both branches. Two Ints give Int. Int and null give Int? (nullable). A branch that throws contributes nothing, so the type comes from the other branch.

Write the label as a name followed by @ directly in front of the loop, like loop@ for (...). To use it, write break@loop or continue@loop with the @ before the name. The label must come before the loop, not after.

By default Kotlin names a lambda's label after the function it's passed to, so you can write return@forEach. You can override that by writing your own label before the lambda, like loop@ { ... }, and then use return@loop.

let, run, apply, etc. are inline, so a bare return inside their lambda returns from the whole enclosing function — not just from the let block. People expect it to stop only the let, which is the bug.

Make the when produce a value so it counts as an expression. The simplest way is to put it after a tiny expression like assigning its result, so the compiler insists every case is handled. In modern Kotlin you also just get a warning automatically.

A comma between conditions means OR: the branch matches if any listed value matches. in range checks membership and !in checks non-membership, working with ranges, collections, or anything defining contains.

Write when {} with no value in the parentheses. Each branch is its own boolean condition, and the first true one wins. It reads more cleanly than a long if/else if chain when you have several unrelated conditions.

A for loop works on anything that provides an iterator. You give your type an iterator() function (or add one as an extension), returning an object with hasNext() and next(). Then for just works on it.

You can make a function body a single if expression with =, no return needed. Branches can be blocks whose last line is the value. Use if for two outcomes; reach for when when you have several cases.

break and continue only work in real loops (for, while). forEach { } is a function taking a lambda, not a loop, so break won't compile there. Inside the lambda you can only return@forEach to skip the current item, which is like continue, not break.

Labels work, but deeply nested labeled jumps get hard to read. Often it's cleaner to pull the nested loops into their own function and use a normal return to exit everything at once, or use a collection operation like firstOrNull.

Only lambdas of an inline function can use a bare (non-local) return. Marking a parameter noinline removes that ability. crossinline keeps the lambda inlined but forbids non-local returns, because the lambda might be invoked from another context.

The compiler can only check a when if it knows every subtype. Sealed types declare all their subtypes up front, so it can. If the value can be null, you must also handle the null case, or the when is not complete.

Branch order matters because the first match wins, so overlapping conditions can change behavior if reordered. Also remember when uses structural equality (==), evaluates the subject once, and stops at the first match — so don't rely on later branches' side effects.

Adding else -> error(...) to a sealed when usually hurts. It silences the compiler check, so when someone adds a new case the code still compiles and only fails at runtime. Without else, the build breaks and points you to every place to fix.

Plain integer for-loops like for (i in 0 until n) compile down to fast counter loops with no boxing. Costs can appear if you turn a range into an object, use very large Long ranges, or box values via generics.

The two branches have different list types, so the variable gets the broader common type (List), losing the mutable API. Watch the inferred type: an if expression widens to whatever both branches share, which may be less than you expect.