[erlang-questions] Which choice is better? Function or Case

[Garrett Smith]

On Thu, Mar 7, 2013 at 3:11 AM, 饕餮 <249505968@REDACTED> wrote:
> I wonder if Function call is better than Case when both of they can
> implement the target I want?
> It seems like  write a function instead of case could make the code more
> clear .
> But which one is fast when it running?
> I intend to change the case to function to make the code more clear. Is this
> valuable?

Over the last year or so, I've started to adopt the approach outlined here:

http://www.gar1t.com/blog/2012/06/10/solving-embarrassingly-obvious-problems-in-erlang/

There are few things I'd like to modify in a followup post [1] but the
general idea of working to make your code "embarrassingly obvious"
still is the central idea.

Functions are the primary mode of "making things obvious". They let
you take otherwise hidden or implicit logic and making it explicit.

The smaller and more focused your functions, the better. You should be
able to look at the function and, in just a moment, know what it does,
without reading comments. If it's not that obvious, ask why, then
clarify it by codifying "what's going on" in functions.

At the time of writing the piece, I didn't have enough experience with
this method to know whether it was Good or Not Good. Today, I believe
that it's Very Good! (with amendments listed below)

Here's why:

- The "obviousness" standard, while subjective, drives a programmer to
think carefully about *everything*, to the point of understanding the
problem/solution ad nauseam

- It shifts the nature of programming from "make the code work" to
"say what I want to say" -- which is a shift away from brute force
experimentation to deliberate problem elaboration/solving (this is why
I advocate trading test time for make-your-code-obvious time)

- Your left with code that's *extremely* maintainable -- neither bugs
nor potential enhancements have anywhere to hide! Any change will
necessarily affect a small surface area that's easy to think about
(while you may see ripple effects across many functions depending on
the change, you'll know the exact boundary)

As to performance, I'll followup with a separate reply, as it involves
large code chunks and this reply is already too long :)

Garrett

[1] There are a few changes I'd like to make to the religious dogma:

1. RoK and others have pointed out -- and I've come to heartily agree
with this -- that the use of variables can help further clarify a
function by a) placing key functions on their own line, thus
highlighting them, b) changing the order things are read from
right-to-left (as in the case of reading function calls) to top-down,
and c) a single variable name can be clearer than a function call with
arguments.

2. While it's possible to replace *all* case expressions with
functions, there are instances where case is clearly better. The
signal is when code becomes decisively *less obvious* without the case
expression. It's a judgement call.

3. In the blog post example, I use a pipeline to convey arguments to a
function. This is very odd indeed -- arguments should be spelled out
and passed discretely to a function, not as an array of values. (In
fact, there's a horrible error in that code, terrible!)

Note that each of these points contributed to reduced lines-of-code
per function. You can see this was clearly a goal of mine!. Since
then, I've relaxed the LoC per function dogma. Though it's still a
good proxy for code quality, just without the authoritarian
religiosity.