From what I’ve seen in other Elixir and Erlang code, it’s typical to name the private functions do_blah when it’s an implementation detail of blah. Since it’s private, it shouldn’t matter much what you choose though. I think it’s more important that it’s near he public function.

Very common for TCO. The extra argument is typically called the accumulator. It’s also a hint that you can turn most recursive operations into a form of reduce to make them TCO.

If it’s my own private code, I sometimes don’t bother with splitting the functions and just pass the accumulator as an optional argument with a default. For example, your faster filter could be defined like this:

  def ffilter(list, func, result \\ [])
  def ffilter([], _, result), do: Enum.reverse(result)
  def ffilter([head | tail], func, result), do:
    # every item that is 👍 is added to it (prepending to LL is cheap)
    # then when we reach the end, reverse and pass it back (reverse is cheap?)
    # Tail-call optimized 👍
    _ffilter(
      tail,
      func,
      (if(func.(head), do: [head | result], else: result))
    )

That’s common. Doing the work in order during recursion can easily recreate an entire list multiple times while prepending to the head is O(1).

Yes, this is a good practice. If you validate at your boundary it means all subsequent code can ignore bad values.

Is do_foo actually common for tail recursive implementations though?

Ultimately functions are not identified by name - they are identified by the combination of name and arity i.e. foo/1 and foo/2 are already different functions. Adopting either do_foo or _foo is equivalent to going down the Hungarian Notation rabbit hole - (many people would argue that if you need type/protection hints then use an IDE rather than burying that information in the function name).

So I’m more familiar with the foo/1 and foo/2 convention to highlight that these distinct functions are part of the same functionality behind the foo name.

I think there is some conflation going on here.

• Being tail recursive and having private access is orthogonal. They may coincide with your choice of implementation. Alternately in Erlang it’s the public function that has to be exported i.e. all functions are private by default.

• That “extra parameter” tends to be a differentiator between implementing body or tail recursion.

  • Body recursion leaves intermediate results on the call stack.
  • Tail recursion explicitly takes control of the “bag of intermediate results” so that it does need to leave additional data on the call stack. So that “extra parameter” is the “bag of intermediate results” that the tail recursion explicitly manages - in a way a faux call stack.

Edit: Changed “stack of intermediate results” to “bag of intermediate results” i.e. holder of intermediate data with whatever internal structure is appropriate to solving the problem.

I picked up the defp _foo() naming convention from one of Dave Thomas’s books and I prefer it to defp do_foo() because having do_ in front of every private function name makes my private function area look like a sea of meaningless do_s and it is harder for me to read quickly.

I also prefer the underscore convention over defp foo() because the underscore makes my code more readable by letting me know in-line that the _foo() function is private and located in the current file. I don’t have to go look for the function definition and figure out where it came from. I instantly know at a glance.

The other nice thing about using defp _foo() for private functions is that underscored function names are not imported into other files. So, if I make _foo() a public function so I can fiddle with it in iex and then forget to make it private again, it still won’t get imported into other modules and accidentally used.