4 ms·
Lets play devils advocate. Does pretty == readable? I consider this: foo(X) -> case X of bar -> void; _Else -> undefined end.
by biokoda 11y ago
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.
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".
- rdtsc 11y ago> Second function requires parsing two fragments of code. foo1 is used to illustrate a point not that you'd name functions like that. The whole thing would be probably: foo(bar) -> void; foo(_) -> undefined. I don't know, I see that better than the case statement.
- biokoda 11y agoAppending 1 to functions is quite common in Erlang for cases such as that. You cant find a good naming scheme for small fragments of ideas.
- rdtsc 11y agoI 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.
- masklinn 11y agoAppending 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.
- polack 11y agoAlso, 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.
- rdtsc 11y agoAh! Very good point. Yes I agree.
- deleted 11y ago[deleted]
- jackweirdy 11y agoDon't know erlang, but why can't the first example be foo(bar) -> void; foo(_Else) -> undefined;
- biokoda 11y agoIt's an overly simplistic example.
- vladimirralev 11y agoIt makes a difference when it's colorized and may be takes some time to get used to but see this for example http://imgur.com/6UYUvye http://imgur.com/6UYUvye
- fenollp 11y agoHello there, fellow Kazoo developer!
- vladimirralev 11y agoHaha, I follow your commits these days :)