When must named arguments be used in function calls?

← Code Quality · Ref: Q694

EK9 requires named arguments in two situations: when passing Boolean values as positional arguments, and when calling functions with 4 or more parameters.

BOOLEAN POSITIONAL ARGS (E11061)

Boolean arguments are ambiguous when positional:

  setMode(true, false)          // E11061: which is which?
  setMode(verbose: true, debug: false)  // Correct: named

4+ POSITIONAL ARGS (E11062)

Functions with 4 or more parameters require named arguments:

  configure("host", 8080, true, "admin")  // E11062
  configure(host: "host", port: 8080, secure: true, user: "admin")  // Correct

WHY THIS MATTERS

Named arguments make call sites self-documenting. Without names, readers must look up the function signature to understand what each argument means.

FEWER ARGS OK

Functions with 1-3 non-Boolean parameters can use positional arguments:

  greet("Alice", "morning")  // OK: only 2 args, no Booleans

See Q314 for naming conventions. See Q322 for code quality metrics. See Q689 for boolean condition patterns.

Example

defines module qa.codequality.namedarguments

  defines function

    <?-
      Function with 4+ parameters.
      Callers MUST use named arguments.
    -?>
    createConnection()
      ->
        hostName as String
        portNumber as Integer
        useTls as Boolean
        connectionTimeout as Integer
      <- connectionInfo as String: `${hostName}:${portNumber} timeout=${connectionTimeout}`

      if useTls
        connectionInfo: connectionInfo + " TLS"

    <?-
      Function with fewer parameters: positional OK.
    -?>
    formatGreeting() as pure
      ->
        recipientName as String
        greeting as String
      <- message as String: `${greeting}, ${recipientName}!`

    <?-
      Function with Boolean parameter: must use named arg.
    -?>
    formatOutput() as pure
      ->
        content as String
        includeTimestamp as Boolean
      <- formatted as String: content

      if includeTimestamp
        formatted: "[timestamp] " + content

  defines program

    NamedArgumentsPatternDemo()
      stdout <- Stdout()

      //4+ params: named arguments required
      connInfo <- createConnection(hostName: "db.example.com", portNumber: 5432, useTls: true, connectionTimeout: 30)
      stdout.println(connInfo)

      //2 non-Boolean params: positional OK
      greeting <- formatGreeting("Alice", "Good morning")
      stdout.println(greeting)

      //Boolean param: named argument required
      output <- formatOutput(content: "hello", includeTimestamp: true)
      stdout.println(output)

Common mistakes

E50060 — String has no toUpperCase() method in EK9. Use upperCase() instead. See ek9 -h E50060 for details.

Incorrect:

stdout.println(output.toUpperCase())

Correct:

stdout.println(output)

E50060 — String has no toString() method in EK9. The variable is already a String. See ek9 -h E50060 for details.

Incorrect:

stdout.println(connInfo.toString())

Correct:

stdout.println(connInfo)

Other ways to ask this

What is E11061 boolean positional argument?
What is E11062 too many positional arguments?
When are named arguments required in EK9?
How do I use named arguments for clarity?

Coming from another language?

Java: no named argument support. Python: named arguments optional. Kotlin: named arguments optional but encouraged. Swift: named arguments required by default. Go: no named arguments. EK9: named arguments mandatory for 4+ params and Boolean params.

Keywords: E11062, E11061, clarity, Boolean, named, function, positional, clean-code, parameter, metric, quality, arguments