skip to content

What are named arguments in Kotlin, and what call-site problems do they solve?

level: juniorimportance: must knowfreq 70%

answer

  1. name = value at the call site
  2. call-site only, declaration unchanged
  3. readability for booleans/ints
  4. skip defaulted params by naming later ones
  5. name must match parameter name

basics

~10 s

Named arguments let you pass a value by writing the parameter's name, like draw(width = 5). This makes calls easier to read and lets you supply only the arguments you want, in any order.

solid answer

~30 s

A named argument is supplied with the syntax name = value at the call site, matching the parameter declared in the function. They improve readability for ambiguous calls (e.g. several Boolean or Int parameters), let you reorder arguments, and let you skip parameters that have default values without listing every preceding one. For example reformat(text, normalizeCase = true) is clearer than reformat(text, true, true, false). They are a call-site-only feature: nothing changes in the function declaration. They pair naturally with default arguments, since skipping a defaulted parameter requires naming the ones you do pass.

code

kotlin · 5 lines
kotlin
fun connect(host: String, port: Int = 443, useTls: Boolean = true) {}

connect("api.example.com")                 // all defaults
connect("api.example.com", useTls = false) // skip port, name the later one
connect(port = 8080, host = "localhost")   // reordered

go deeper

for a junior

Can state the name = value syntax and that it improves readability and lets you skip defaulted parameters.

for a middle

Explains the reorder/skip mechanics and that renaming a parameter breaks named callers.

for a senior

Frames named args as a call-site contract, ties them to default arguments and API ergonomics/evolution.

for a principal

Discusses parameter names as public API surface and stability implications across a codebase or library.

## What a named argument is In Kotlin you can pass an argument to a function by writing the **parameter name** followed by `=` and the value, instead of relying on position. This is a **call-site** feature — the function declaration is unchanged. ```kotlin fun reformat( text: String, normalizeCase: Boolean = true, upperCaseFirstLetter: Boolean = true, divideByCamelHumps: Boolean = false, wordSeparator: Char = ' ', ) { /* ... */ } // positional — what do these booleans mean? reformat("hello", true, true, false, '_') // named — self-documenting reformat("hello", normalizeCase = true, wordSeparator = '_') ``` ## Problems they solve - **Readability**: long parameter lists, especially with several `Boolean`/`Int`/`Char` values, are hard to read positionally. Names make each value's meaning explicit at the call site. - **Skipping defaults**: when a parameter has a **default value**, you can omit it. But to skip one in the *middle* and still pass a later one, you must name the later argument — otherwise position would be ambiguous. - **Reordering**: once you start using names, you can list arguments in any order you like. ## Key rules - The name must exactly match the **parameter name** in the declaration. Renaming a parameter is therefore a source-breaking change for callers using names. - Named arguments don't require default values — you can name every argument of any Kotlin function. - They work with regular and `vararg` parameters, with one caveat covered in advanced questions (spread vs. multiple named values). ## Quick mental model Think of named arguments as filling in a labeled form rather than handing values across a counter in a fixed order.

  • Do named arguments change anything about how the function is declared?
    No. They are purely a call-site convenience; the function signature is identical whether callers use positional or named arguments.
  • If you rename a parameter, what happens to callers using named arguments?
    Their calls break at compile time because the name no longer matches. Parameter names are part of the call-site contract.

Like filling in a labeled form instead of passing values across a counter in a fixed order.

saying these in an interview costs you the question

  • Claiming named arguments require default values to be used
  • Thinking the function declaration must be marked specially to allow named calls
  • Saying the value name can differ from the parameter name
  • Believing named arguments are a runtime feature with overhead

context

resolving links…