we’ve deviated considerably from the main point, but I don’t think it’s bikeshedding and helping people craft clear code is important enough to merit discussion.
In the specific example you gave, I think if you’re creating a work function in a module called Accept.List, it probably shouldn’t take “nil” as a parameter defensively. It should only take lists. Already from how it’s been coded I can tell that the upstream caller is using get inappropriately and should instead be using, fetch! or fetch function instead. Understandably, not everyone follows these naming conventions, naming is hard and even I screw this up… a lot… in my private code, and periodically i have to go thorough and clean them up. Fetch is too tempting a name to refer to “going some long distance and getting data” instead of “this returns error/ok tuples”, but I do also think that respecting conventions is important.
if you have a function that can emit nil, you should probably be immediately consuming it in something that can deal with nils, and usually something that comes from stdlib/stdlib adjacent, so if, cond, to_string, List.wrap. Phoenix.HTMLSafe, etc.
For example, this is a pattern I use a lot:
Enum.flat_map(list_of_selected_keys, &List.wrap(if value = Map.get(map, &1), do: value))
That one could be a matter of taste because you can certainly do a filter on the list of selected keys, noting that the filter alternative does result in you potentially iterating through the list of keys twice.
But the one that is hard is when you have a cond:
cond do
attempt1 = get_from_source_1(key) -> attempt1
attempt2 = get_from_source_2(key) -> attempt2
attempt3 = get_from_source_3(key) -> attempt3
...
end
I somewhat dislike doing a reverse with, which is the most legible alternative:
with :error <- fetch_from_source_1(key),
:error <- fetch_from_source_2(key)
...
else
{:ok, result} -> result
end
I think it is a good thing to be used to reading railroad code as a list of successes. I find that reading over code that I myself wrote where I have a reverse with, even though I always put a comment warning me that this with statement is a reverse with, will still cause my brain to trip up and have to recontextualize, so I have stopped writing reverse withs.
There’s another List.wrap example
developing_list = [...] ++
List.wrap(if must_be_2nd_last = Keyword.get(opts, :foo), do: must_be_2nd_last) ++
List.wrap(if must_be_last = Keyword.get(opts, :bar), do: must_be_last)
if you only had one, you could do it pretty easily with a case statement and Keyword.fetch, avoiding nils, but it gets hairy with more than one.
In most Elixir project I was in there was no mindset of “our project can raise” or “our project must NEVER raise” so we kind of knew the default by heart and this was not enforced with syntax conventions.