How does EK9 prevent excessive Boolean parameters?

← Code Quality · Ref: Q698

EK9 flags Boolean parameters that create unclear APIs. Boolean arguments at call sites are ambiguous without named arguments.

BOOLEAN PARAMETER WARNING (E11061)

Methods with Boolean parameters require callers to use named arguments to avoid ambiguity:

  process(true, false)           // E11061: ambiguous
  process(verbose: true, debug: false)  // Clear

WHY BOOLEANS ARE PROBLEMATIC

At the call site, bare true/false conveys no meaning:

  createUser("Alice", true, false, true)  // What do these mean?

CORRECT PATTERNS

1. Use named arguments for Boolean parameters
2. Store Boolean values in named variables before passing
3. Consider using enumerations instead of Boolean flags

ENUMERATION ALTERNATIVE

Instead of Boolean flags:

  LogLevel with INFO, DEBUG, TRACE
  setLogging(level: LogLevel.DEBUG)

NAMED VARIABLE PATTERN

  isVerbose <- true
  setMode(verbose: isVerbose)

See Q694 for named arguments pattern. See Q689 for boolean condition patterns. See Q314 for naming conventions.

Example

defines module qa.codequality.booleanparams

  defines function

    <?-
      Function with Boolean parameter.
      Callers must use named argument for the Boolean.
    -?>
    formatMessage()
      ->
        messageText as String
        includePrefix as Boolean
        useColor as Boolean
      <- formatted as String: messageText

      if includePrefix
        formatted: "[MSG] " + messageText

      if useColor
        formatted: `<c>${formatted}</c>`

    <?-
      Using named variables for Boolean values.
      The variable name documents the intent.
    -?>
    processEntry()
      ->
        entryText as String
        shouldValidate as Boolean
      <- result as String: entryText

      if shouldValidate
        trimmed <- entryText.trim()
        if trimmed?
          result: trimmed

  defines program

    ExcessiveBooleanParamsDemo()
      stdout <- Stdout()

      //Named arguments for Booleans: clear intent
      msg <- formatMessage(messageText: "hello", includePrefix: true, useColor: false)
      stdout.println(msg)

      //Named variable pattern: descriptive name
      needsValidation <- true
      processed <- processEntry(entryText: "  data  ", shouldValidate: needsValidation)
      stdout.println(processed)

Common mistakes

E11061 — Boolean arguments must be passed BY NAME so each true/false is self-documenting. Passing two positional Boolean literals (true, false) triggers E11061 - name them (includePrefix: true, useColor: false). See ek9 -h E11061 for details.

Incorrect:

formatMessage("hello", true, false)

Correct:

formatMessage(messageText: "hello", includePrefix: true, useColor: false)
Other ways to ask this
  • What is E11061 excessive Boolean parameter?
  • Why does EK9 flag Boolean parameters?
  • How should I handle methods with Boolean flags?
  • What is the correct pattern for Boolean parameters?

Coming from another language?

Java: no enforcement (spotbugs may warn). Python: no enforcement. Kotlin: named arguments help but not required. Swift: external parameter names help. Go: no enforcement. EK9: Boolean params require named arguments at call site.

Keywords: named, Boolean, E11061, flag, metric, clarity, clean-code, ambiguous, argument, quality, parameter