Why does EK9 reject a method or function that has too many statements?

← Code Quality · Ref: Q1335

EK9 measures a raw SIZE metric - the number of statements in each function, method, operator and service operation - separately from cyclomatic complexity (E11010). Each variable declaration, assignment, control-flow entry, throw and call counts as one statement. When the count exceeds the threshold the compiler raises E11012. The thresholds are: operators 50, methods 100, functions 150, service operations 100.

A long function is doing too much, so the fix is to identify logical groups of statements and extract each into a well-named helper function with a single responsibility. The original function then becomes a short sequence of calls, and every unit drops well under the threshold.

Note E11012 is a pure size check: it fires even when each statement is trivial and the cyclomatic complexity is low. See Q696 for the complexity-limit catalogue. See Q1020 for refactoring techniques. See Q311 for quality checks.

Example

defines module qa.quality.statement.count

  defines function

    //FIX: each logical sub-task lives in its own small focused function,
    //so no single function approaches the 150-statement threshold.

    sumValues() as pure
      -> values as List of Integer
      <- rtn as Integer: 0
      for value in values
        rtn: rtn + value

    averageValue() as pure
      ->
        values as List of Integer
        total as Integer
      <- rtn as Integer: 0
      count <- length values
      if count > 0
        rtn: total / count

    formatReport() as pure
      ->
        total as Integer
        average as Integer
      <- rtn as String: `total=${total} average=${average}`

    //The orchestrating function is now a short sequence of calls,
    //well under the statement-count limit.
    buildReport() as pure
      -> values as List of Integer
      <- rtn as String?
      total <- sumValues(values)
      average <- averageValue(values, total)
      rtn: formatReport(total, average)

  defines program

    StatementCountDemo()
      stdout <- Stdout()
      values <- [10, 20, 30, 40]
      stdout.println(buildReport(values))

Common mistakes

E11012 — Putting 160+ statements directly in one function exceeds the function threshold of 150 (methods 100, operators 50, service operations 100), so the compiler raises E11012 - a size check distinct from cyclomatic complexity. Identify logical groups (sum, average, format) and extract each into its own named helper, then call them in sequence; every unit then falls under the threshold. See ek9 -h E11012 for details.

Incorrect:

buildReport()
  -> values as List of Integer
  <- rtn as String?
  // 160+ inline statements computing the total, the average and the
  // formatted text all in one body

Correct:

    buildReport() as pure
      -> values as List of Integer
      <- rtn as String?
      total <- sumValues(values)
      average <- averageValue(values, total)
      rtn: formatReport(total, average)

Coming from another language?

Java: method length is unbounded; only optional tools (Checkstyle MethodLength, PMD ExcessiveMethodLength, SonarQube) flag long methods, and they emit warnings teams routinely suppress. Kotlin/Swift/Go: no built-in statement-count limit; detekt/SwiftLint can warn if configured. EK9: statement count is a hard compile error (E11012) per function/method/operator/service-operation, so an oversized unit simply does not compile.

Keywords: function, extract, count, decompose, size, quality, E11012, method, statement