Default arguments best practices?

Oh, I am not against keyword lists as options, of course. That’s one of the gems in Elixir: it allows you to emulate named function arguments and it is super convenient!

My objection is towards more than one optional function argument (i.e. 2 or more having default values). That becomes messy super quickly.

I hate to even write any of this post because I fear it can be taken the wrong way. I do understand that you made a particular recommendation but I still have no idea why. What’s the downside of using an opts list? Can you give some concrete examples that show why its a bad idea?

There is a good chance where even your own application code becomes so large that changing all call sites would produce pull requests that touch hundreds of files spanning multiple teams.

So your advice also holds for application code I think and not just libraries.

Agreed 100%. Indeed the emphasized part IMO goes without saying. Hence my original statement didn’t include it.

Plus, @derek-zhou, more than one default argument is something that I don’t remember the last time that I needed it.

…plus you can now use treasures like Keyword.validate! or NimbleOptions.

Sure, there is always the caveat of not breaking existing code. But “never do it if you can avoid it” I think is always implicit in this kind of advice. I don’t see how in top_n/4 the fourth arg only makes sense with the 3rd arg. Those both look like things I’d want to be able to specify independently.

I think for libraries who have to avoid breaking changes, you should begin with options lists over even a single optional argument, so that you never have this problem. In our own application code it’s a different story as we can update all callers when we change the function. Even still, all cases where I used to reach for optional args I now instead use options lists. All of the benefits, none of the downsides.

Of course you can achieve that with keyword list. However, multiple default arguments still has its place:

• At the beginning, there was only one default argument. however, later on you need to add another, and you don’t want to break existing code . There are cases in the standard library, like Enum.min/3
• the second default argument may only make sense with the first default argument already there, eg:

def top_n(table, n, sorted_field \\ :id, sorted_fun \\ &<=/2)

Totally agree. I made a whole mess by having more than one default argument (that too booleans, those are the worst)

You know, it really bothers me knowing that KW lists require O(n) iteration over the list to extract the argument. I know full well that it will (almost) never matter in practice and I’m pretty sure it’s actually pushed down to native code, but I wince every time anyway…

Of course, I still use them frequently because named args can’t be beat for readability when you have a lot of them.

I personally have found default arguments to be a good tool for trolling, as the default arguments are not restricted to the last arguments only as in many other languages, hence this is valid code too:

def(param1 \\ %{}, param2 \\ "", param3, param4 \\ []) do
# param3 is not optional
end

I don’t see why you’d need multiple default arguments for that? You can detect presence with keyword lists and derive defaults etc.

Keyword.put_new_lazy(opts, :key, fn -> 
  other_value = opts[:other_key]
  some_function_of(other_value)
end)