Timeline for How do I edit a chain of if-else if statements to adhere to Uncle Bob's Clean Code principles?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 2, 2024 at 14:54 | comment | added | ps2goat | Not only is length a factor, like @FrankHopkins mentioned, but when different state is looked at in the subsequent if blocks. I've seen some complex, 600+ line functions where one variable is checked in the first if, then used again 3-4 else ifs later. If multiple bits of state are checked in different ways, it becomes really hard to keep track of all that in your head. | |
| Feb 21, 2023 at 15:56 | vote | accept | Ev0oD | ||
| Feb 20, 2023 at 18:26 | comment | added | maple_shaft♦ | @KulaGGin Please try to avoid general chat in answer comments if possible. Comments should be used to ask for clarification on the answer or direct feedback to improve it. All other conversations should be held in our chat. | |
| Jan 20, 2018 at 16:15 | comment | added | Frank Hopkins | @MichaelKjörling For a short statement I can follow your argument, though I wouldn't make it myself. But the longer a method gets - the more if-else-if constructs it contains, the more a clear exit point where I know I can ignore the rest of the method if I get there outweighs the possible benefit of the if-else. This also helps keeping the depth of the if -else statements low, which makes it way more readable. | |
| Jan 15, 2018 at 13:47 | comment | added | Jesus is Lord | "And remember, don't get religious even about this advice as well." +1 | |
| Jan 15, 2018 at 6:43 | comment | added | user949300 | Coming from JavaScript/node.js, some would use the "belt and suspenders" code of using both else if and return. e.g. else if(...) { return alert();} | |
| Jan 14, 2018 at 22:57 | comment | added | cmaster - reinstate monica | @MichaelKjörling Full Ack.I would myself prefer the else if construct, especially since its chained form is such a well-known pattern. However, code of the form if(...) return ...; is also a well-known pattern, so I would not fully condemn that. I see this really as a minor issue, though: The control flow logic is the same in both cases, and a single closer look at a if(...) { ...; return; } ladder will tell me that it's indeed equivalent to an else if ladder. I see the structure of a single term, I infer its meaning, I realize that it's repeated everywhere, and I know what's up. | |
| Jan 14, 2018 at 20:21 | comment | added | user | I know, it's a small thing, but at least to me, else if forms one semantic unit. (It's not necessarily a single unit to the compiler, but that's okay.) ...; return; } if (... doesn't; let alone if it's spread out on multiple lines. That's something I'll actually have to look at to see what it's doing, instead of being able to take it in directly by just seeing the keyword pair else if. | |
| Jan 14, 2018 at 20:20 | comment | added | user | I'd argue that replacing else if with an inner return followed by a simple if (removing the else) might make the code more difficult to read. When the code says else if, I immediately know that the code in the next block will only ever execute if the previous one didn't. No muss, no fuss. If it's a plain if then it might execute or it might not, irrespective of whether the previous one executed. Now I'll have to expend some amount of mental effort to parse the previous block to note that it ends with a return. I'd rather spend that mental effort on parsing the business logic. | |
| Jan 12, 2018 at 12:27 | history | answered | cmaster - reinstate monica | CC BY-SA 3.0 |