4 ms·
The way empty? is implemented is literally an implementation detail, so it's somewhat irrelevant to the discussion of readability. Regarding the last example:
by lambdadmitry 9y ago
The way empty? is implemented is literally an implementation detail, so it's somewhat irrelevant to the discussion of readability.
Regarding the last example: I would say
(->> [a b c] (remove nil?) first)
is even better. However, if that vector is effectively a tuple (so a, b, and c are heterogenous and can be named), cond is more explicit and readable.
- dghf 9y ago> However, if that vector is effectively a tuple (so a, b, and c are heterogenous and can be named), cond is more explicit and readable. I don't understand. Could you illustrate with an example?
- lambdadmitry 9y agoSorry, I forgot the original snippet and though about something else (working over sequences). However, in the original context it makes even more sense to use cond as the number of variables is clearly limited (and they probably have meaningful names).
- dghf 9y ago> However, in the original context it makes even more sense to use cond as the number of variables is clearly limited (and they probably have meaningful names). But the construct with remove and first can be applied to a limited number of variables with meaningful names just as easily as the cond construct. Plus it has these advantages: - It's shorter. - It avoids jarring repetition. - It's more readable, I'd argue, than the cond version: in the threading-macro version you offered, it translates directly into English as "take a sequence, strip out the nil values, and return the first item of what's left". - It can be applied equally in situations where the number of items is known at compile time, and those where it isn't. - It can be applied to an arbitrarily large number of items.