What is the maximum nesting depth allowed in EK9 and why?
← Code Quality · Ref: Q728
EK9 limits control flow nesting to 6 levels. Each nested if, while, for, switch, or try block increments the depth counter. Exceeding 6 triggers E11011.
WHY 6 LEVELS
Research shows that code comprehension drops sharply beyond 3-4 levels of nesting. At 6 levels, a reader must track 6 simultaneous conditions to understand which branch executes. This is a maintenance and review burden that grows exponentially.
THIS IS A DESIGN LIMIT, NOT A TECHNICAL ONE
The compiler could handle 100 levels of nesting. The limit exists because deeply nested code is:
1. Hard to review: reviewers miss edge cases in deeply nested branches
2. Hard to test: each nesting level multiplies the number of test paths
3. Hard to modify: adding a condition at level 5 requires understanding levels 1-4
4. A code smell: deep nesting usually means the function is doing too much
HOW TO STAY WITHIN LIMITS
- Extract nested logic into helper functions (each function resets nesting)
- Use guard expressions to flatten conditional chains
- Use switch instead of chained if/else where appropriate
- Apply early filtering with stream pipelines
THIS EXAMPLE
The processConfiguration function below uses exactly 6 levels of nesting. It compiles because 6 is the maximum allowed. Adding a 7th level inside the innermost block would trigger E11011.
See Q696 for complexity limits. See Q310 for code quality overview. See Q322 for quality enforcement.
Example
defines module qa.codequality.nestingboundary defines constant NETWORK_SECTION <- "network" STORAGE_SECTION <- "storage" APP_CONFIG <- "app" MIN_SETTING_LENGTH <- 3 defines function <?- Helper function to check if a setting is enabled. -?> isEnabled() as pure -> setting as String <- enabled as Boolean: length setting > 0 <?- Helper function to check if a setting name is valid. -?> isValidSetting() as pure -> settingName as String <- isValid as Boolean: length settingName > 1 <?- This function uses exactly 6 levels of nesting. This is the maximum allowed by EK9 before E11011 triggers. Level 1: if configName? Level 2: if sectionName? Level 3: switch on section Level 4: if settingName? Level 5: if isEnabled check Level 6: if length check -?> processConfiguration() -> configName as String sectionName as String settingName as String <- message as String: "no action" //Level 1 if configName? //Level 2 if sectionName? //Level 3: switch counts as a nesting level switch sectionName case NETWORK_SECTION //Level 4 if settingName? activated <- isEnabled(settingName) //Level 5 if activated //Level 6: this is the maximum depth if length settingName > MIN_SETTING_LENGTH message: "configured" case STORAGE_SECTION message: "storage handled" default message: "unknown section" defines program NestingDepthBoundaryDemo() stdout <- Stdout() stdout.println(processConfiguration(APP_CONFIG, NETWORK_SECTION, "proxy")) stdout.println(processConfiguration(APP_CONFIG, NETWORK_SECTION, "")) stdout.println(processConfiguration(APP_CONFIG, STORAGE_SECTION, "cache")) stdout.println(processConfiguration("", "", ""))
Common mistakes
E50001 — The function processConfig is not defined in this module. The correct function name is processConfiguration. See ek9 -h E50001 for details.
Incorrect:
stdout.println(processConfig(APP_CONFIG, NETWORK_SECTION, "proxy"))
Correct:
stdout.println(processConfiguration(APP_CONFIG, NETWORK_SECTION, "proxy"))
Other ways to ask this
- What triggers E11011 excessive nesting?
- How deep can I nest if statements in EK9?
- What is the nesting depth limit?
- Why does EK9 limit control flow nesting?
Coming from another language?
Java: no nesting limit (checked by optional tools like Checkstyle). Python: no formal limit (PEP 8 discourages deep nesting). C++: no limit. Rust: no limit (Clippy may warn). Go: no limit (convention discourages). EK9: 6-level hard limit enforced at compile time.
Keywords: depth, while, limit, nesting, if, E11011, boundary, clean-code, metric, quality, complexity, switch