Lets play devils advocate. Does pretty == readable?
I consider this:
foo(X) ->
case X of
bar -> void;
_Else -> undefined
end.
More readable than:
foo(X) -> foo1(X).
foo1(bar) -> void;
foo1(_Else) -> undefined.
First function is parsable in its entirety immediately. It conveys an idea in a single fragment, which is not too large and it is not too small. Foo executes depending on value of X.
Second function requires parsing two fragments of code. It requires a not-so-pretty naming scheme of appending 1 to the function. And you can not grasp the entirety of the matter in a single glance. To parse this function you must follow a train of thought: foo -> foo1 -> execute depending on X.
Second function style of code results in a million functions in a single module which I very much disagree results in more readable code.
I fail to see how second foo is more clear. In Erlang maybe value can be absolutely anything. It is unnecessary verbose. The explanation on what is wrong with first function contains way to many "shoulds" and not enough "becauses".
Also, adding an "catch all" is usually not recommended in Erlang (even though it's good for some things), so most of the time you would do just: foo(bar) -> void.
And then let it crash if the value is something else than expected.
I don't know, I find I do it with variables more than functions. With functions I seprate them by arity, so there could be a foo/0 and foo/1 maybe. But usually I haven't seen much fun1 fun2 fun3 ... pattern.
And if you don't see a way, don't split it. I mean, make your code look good and easy to understand for yourself and others, that's the point.
Appending 1 to functions might be used for utility/internal functions with a slightly different (and less convenient) signature than the base[0], usually because the original signature does not allow for tail-recursion. That's not the case here.
I consider this:
foo(X) ->
More readable than:foo(X) -> foo1(X).
foo1(bar) -> void;
foo1(_Else) -> undefined.
First function is parsable in its entirety immediately. It conveys an idea in a single fragment, which is not too large and it is not too small. Foo executes depending on value of X.
Second function requires parsing two fragments of code. It requires a not-so-pretty naming scheme of appending 1 to the function. And you can not grasp the entirety of the matter in a single glance. To parse this function you must follow a train of thought: foo -> foo1 -> execute depending on X.
Second function style of code results in a million functions in a single module which I very much disagree results in more readable code.
Moving on to next example:
foo(X) -> final_function(maybe_function(X)).
foo(X) -> Maybe = maybe_function(X), final_function(Maybe).
I fail to see how second foo is more clear. In Erlang maybe value can be absolutely anything. It is unnecessary verbose. The explanation on what is wrong with first function contains way to many "shoulds" and not enough "becauses".