How does EK9 prevent excessive Boolean parameters?

← Code Quality · Ref: Q698

EK9 flags call sites that pass Boolean literals in a way that creates unclear code. Having a Boolean parameter is not an error by itself.

POSITIONAL BOOLEAN LITERALS (E11061)

A call that passes two or more Boolean literals positionally is rejected. Name the arguments to avoid ambiguity:

  process()
    ->
      verbose as Boolean
      debug as Boolean
    <- rtn as Boolean: verbose and debug
  r1 <- process(true, false)           // E11061: ambiguous
  r2 <- process(verbose: true, debug: false)  // Clear
  stdout.println(`${r1} ${r2}`)

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 should name the Boolean arguments (two positional Boolean literals are E11061).
    -?>
    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: a call passing two or more positional Boolean literals is a compile error (E11061); name them.

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