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
Each level of nesting is one more condition a reader must hold in mind. At 6 levels, a reader must track 6 simultaneous conditions to understand which branch executes, and every further level adds to the maintenance and review burden.
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 guards 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
#!ek9 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: E11011, boundary, clean-code, complexity, depth, if, limit, metric, nesting, quality, switch, while