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

[Robert Raschke]

I would go so far to say that every programmer in the world would like to
name things appropriately. But finding the right names can be hard and time
consuming. And it is this time that is required for good naming that is
often sacrificed by *managers* who are unwilling to understand the impact
of poor naming. A good review structure will quite easily rectify naming
deficiencies. Getting (or making) time for proper reviews is a big
challenge in almost all organisations that write programs (this includes
open source efforts).

There is one class of program where this is not a problem: use-once
programs. But unfortunately, these have a habit of surviving attempts to
destroy them.

Robby
On Mar 10, 2013 3:33 PM, "Thomas Allen" <thomas@REDACTED> wrote:

> On 3/10/13 4:27 AM, ok@REDACTED wrote:> I'm trying to think of
> anything nastier for a programmer to
> > do to another programmer than to know something the second
> > programmer needs to know and deliberately choose to conceal
> > it by using ultra-short variable names.  If I have any luck
> > I'll let you know.
> >
> > Seriously, the job of a programmer is to *COMMUNICATE* with
> > other programmers.  I wish I could offer a simple rule for
> > how long to make variable names.  My colleague who refuses
> > to use "i" for a loop index in C++, preferring
> > innerLoopIndex, clearly errs on one side.  Someone who uses
> > T for timestamp, tree, and table in the same module clearly
> > errs on the other.
>
> I agree with this, to a point. Few things irk me as much as
>
>     Ret = fish_bowl:boil(Bowl, timer:minutes(3)),
>     %% ...
>     Ret.
>
> I've seen many high quality projects that do this, so I cannot criticize
> the technique as some engineering downfall, but never once have I
> encountered a variable of this sort that was not better served by a
> descriptive name. In this case, perhaps `Boiled' is the correct name.
>
> However, this has more to do with variable names that mean nothing in
> context. There's no sense in proscribing short variable names without
> consideration.
>
> Suppose a function that searches a list of `dict()`s which are expected to
> simply store `term()`s for the user, where we cannot infer the type or
> other nature of the value. In that function, I believe that variable names
> such `K' and `V' are entirely suitable, just as `X' and `N' fit comfortably
> in a mathematical function.
>
> What I don't like is variable names like `X', `X1', `X2' in a function
> that is not mathematical at all. Even if a program is full of nothing but
> the simplest functions, their clauses must still be maintained by somebody,
> and there's no sense in deliberately providing vague, short variable names
> simply for the sake of narrower code or less typing.
>
> Of course, there are exceptions to every rule ... "A foolish consistency
> is the hobgoblin of little minds."
>
> Thomas Allen
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130310/0eb6656c/attachment.htm>