Timeline for Best practice for redundant conditions in if-elif-else statements
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 11, 2023 at 17:55 | vote | accept | Nikhil Kumar | ||
| Oct 11, 2023 at 17:55 | |||||
| Oct 11, 2023 at 14:38 | comment | added | Matthieu M. | @BlackJack: You're misunderstanding my comment. I am referring to replacing the last elif by an else + assert, not about adding an else that should never be taken. In the latter case (never be taken), then no condition need be checked, it's an unconditional throw. Just raise (or use assert False if you so wish). | |
| Oct 11, 2023 at 14:23 | comment | added | BlackJack | @MatthieuM. The assumption at that point is n == 0 or n < 0 or n > 0. But I don't see a point in repeating the conditions as this is repeated code which must be kept in sync. I would use assert False, f"unexpected value {n}". | |
| Oct 11, 2023 at 10:07 | comment | added | Matthieu M. | @EricDuminil: If you replace elif n > 0: by else:, I'd write assert(n > 0), since that's the assumption being made. | |
| Oct 11, 2023 at 9:15 | comment | added | Eric Duminil | @MatthieuM.: Which assert would you write? | |
| Oct 10, 2023 at 19:00 | comment | added | Indigenuity | I was tempted to agree with OP on their choice of including coding-style as a tag on the question. This answer makes me want to reassess all my own "styles" to see what incorrectness I've been hiding | |
| Oct 10, 2023 at 13:36 | comment | added | T.E.D. | Doing relational logic on floats is not for the feint of heart. | |
| Oct 10, 2023 at 10:05 | comment | added | Matthieu M. | @aaaaaa: I'm not a fan of letting bugs in in the name of "friendliness" or "productivity". Instead, I'd recommend having the discussion once, with the team, coming to an agreement, and making it a review guideline with a link to the summary of the discussion. Anybody who wishes to challenge the discussion in the future is welcome to, but should first acquaint themselves with the summary and ensure their arguments are genuinely new. | |
| Oct 9, 2023 at 19:23 | comment | added | aaaaaa | I think one thing to note is that although small things like this might feel more right to one person or another and are perfectly fine to discuss when writing your own code - don't let it impede team PRs because it's too small to start a debate over. I've gotten more and more frustrated over the years at different employers where these conversations take up way too much time when instead our team could be moving forward. | |
| Oct 9, 2023 at 13:38 | history | edited | Oscar Cunningham | CC BY-SA 4.0 | edited body |
| Oct 9, 2023 at 13:22 | comment | added | Falco | For the fast reader (skimming over longer code) using else will make clear "one of these cases will be executed for sure". Using only if/else-if always implies "this may be optional - there may be cases which skip over this block". (and the compiler may see it the same way, e.g. warning about an uninitialized variable, if you have no else case) | |
| Oct 9, 2023 at 13:03 | comment | added | Matthieu M. | This. Either use an else for a catch-all, or use else for the last case with an assert. In either case, double-check that you did account for all situations. | |
| S Oct 9, 2023 at 13:00 | review | First answers | |||
| Oct 9, 2023 at 13:20 | |||||
| S Oct 9, 2023 at 13:00 | history | answered | Oscar Cunningham | CC BY-SA 4.0 |