How do else-if chains work in Java, and how does ordering affect which branch runs?
answer
- no elseif keyword — it's else { if } flattened
- top to bottom, first true wins, rest skipped
- mutually exclusive: at most one branch runs
- order specific/high-priority first to avoid shadowing
- single-value-vs-constants → prefer switch
basics
~10 sAn else-if chain tests conditions in order from top to bottom. The first condition that is true runs its block, and the rest are skipped. An optional final else catches everything else.
solid answer
~40 sJava has no dedicated `elseif` keyword; an else-if chain is just an `if` whose `else` branch is another `if` statement, written on one line by convention. Conditions are evaluated **top to bottom**, and the **first** one that is true runs its block; all later conditions are skipped entirely (they are never even evaluated). A trailing bare `else` acts as the default. Ordering therefore matters: more specific or higher-priority conditions must come first, because a broad earlier condition can shadow a narrower later one. For example, testing `score >= 50` before `score >= 90` would never reach the 90 branch. For ranges, order them so each branch implicitly assumes the previous ones were false. When branching on a single value against constants, a `switch` is often clearer.
code
java · 7 linesint score = 95;
char grade;
if (score >= 90) grade = 'A';
else if (score >= 80) grade = 'B';
else if (score >= 50) grade = 'C';
else grade = 'F';
// grade == 'A'go deeper
Can write a multi-branch else-if chain and knows the first true condition wins.
Orders range conditions correctly, recognizes shadowing bugs, and knows each later branch assumes the earlier ones failed.
Chooses between else-if and switch deliberately, simplifies chains with guard clauses or polymorphism, and spots unreachable branches in review.
Sets guidance on replacing sprawling conditional chains with polymorphism or strategy patterns, and weighs readability vs. exhaustiveness checking across the codebase.
## The problem: more than two outcomes A plain `if/else` picks between two paths. Often you need several mutually exclusive outcomes — e.g. grade A/B/C/F. The **else-if chain** handles this. ## There is no `else if` keyword Java only has `if` and `else`. What looks like `else if` is simply an `else` whose single statement happens to be another `if`: ```java if (a) { ... } else { if (b) { ... } else { ... } } ``` Because an `if` is itself a single statement, the inner braces are optional, so everyone writes the flattened, readable form: ```java if (a) { ... } else if (b) { ... } else if (c) { ... } else { ... } // default, optional ``` These are semantically identical — the chain is pure nesting that the formatting hides. ## Evaluation order and short-circuit selection Conditions are tested **top to bottom**. The **first** condition that evaluates to `true` runs its block, and then the **entire chain is exited** — no later conditions are evaluated, even if they would also be true. This makes the branches **mutually exclusive**: at most one block runs. The optional trailing `else` runs only if *every* condition was false. ## Why ordering matters Because selection stops at the first true condition, a broad condition placed early can **shadow** (hide) a narrower one placed later. Consider grading: ```java // WRONG order if (score >= 50) grade = 'C'; // 95 matches here first! else if (score >= 90) grade = 'A'; // unreachable for high scores ``` A score of 95 satisfies `>= 50` first, so it gets a 'C' and the 'A' branch is never reached. The fix is to order from most specific/highest threshold to least: ```java if (score >= 90) grade = 'A'; else if (score >= 80) grade = 'B'; else if (score >= 50) grade = 'C'; else grade = 'F'; ``` Now each later branch can safely *assume* the earlier conditions were false (e.g. by the time you reach `>= 80`, you already know score < 90), so you only test the new lower bound. ## Relationship to switch When all branches compare **one variable** against **constant values**, a `switch` statement (or modern `switch` expression) is usually clearer and lets the compiler check for missing cases. Use an else-if chain when conditions are ranges, involve different variables, or use complex boolean logic. ## How to derive the answer at any level Read the chain as: "try each test in order; take the first that passes; if none pass, take the else." Then ask "could an earlier test accidentally swallow a later one?" — that question is the whole ordering insight.
- If two conditions in the chain are both true, which block runs?Only the first one in top-to-bottom order. Once a condition matches, the chain exits and remaining conditions are never evaluated.
- When would you choose a switch over an else-if chain?When branching on a single variable compared to constant values (ints, strings, enums). switch is clearer and, as a switch expression, can enforce exhaustiveness over enums.
saying these in an interview costs you the question
- Thinking all matching branches run (only the first true one does)
- Putting the broadest condition first and wondering why later branches never fire
- Believing later conditions are still evaluated after a match