[another-dave]

> 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]

> an empty collection isn't a "bad"

Then you don't need to check if it's empty to begin with.

[Xelynega]

I 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]

Yes 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?