4 ms·
> Think it this way: you're going to split the conditions into two: `users` is non-empty, which is the "good" condition; and `users` is empty, which is the "bad
by another-dave 4y ago
> Think it this way: you're going to split the conditions into two: `users` is non-empty, which is the "good" condition; and `users` is empty, which is the "bad" condition.
In a lot of cases though, an empty collection isn't a "bad" condition at all, e.g. it's a valid collection to apply filters/maps to.
Similarly when people get used to doing "if not i" for ints, but then forget about the times that zero is a valid value.
It's true that dynamic coercion is a feature of the language, but coding conventions generally are often about enforcing "least surprise" to remove a burden from the person reading the code.
- thrdbndndn 4y ago> an empty collection isn't a "bad" Then you don't need to check if it's empty to begin with.
- Xelynega 4y agoI think they're making the distinction between special cases and error cases. An empty list could be valid(e.x. a search of users providing no results) so you still need to differentiate between "special cases that need special logic" and "bad input". Lumping the two together in one `if` block makes any code less readable imo, because they're not the same thing.
- another-dave 4y agoYes agreed but the trouble being that if you see "if not users", you've to second guess the intent of behind it. Is an empty list being routed to the else branch because it is an error in this instance or because it's an error in 90% of the codebase so the author forgot to handle it explicitly here? Or is the author always expecting users will be a full or empty list and that other falsy values will never occur?