[erlang-questions] Simple Erlang Recommendation (last returned value)

[Hynek Vychodil]

On Sun, Jul 27, 2008 at 10:56 AM, <attila.rajmund.nohl@REDACTED> wrote:

> On Sat, 26 Jul 2008, Alain O'Dea wrote:
>
> > On 26-Jul-08, at 6:47 PM, James Hague wrote:
> >
> >>> Imagine this:
> >>>
> >>> X = tl(L),
> >>> ... many messy lines ...
> >>> *X = tl(X),
> >>> ... another many lines ...
> >>> *X = tl(X),
> >>> ... another many almost unreadable messy lines ...
> >>> sensitive_usage(X), % <--- buggy X value observed here
> >>>
> >>> And my question is, where Value of X came from? It goes from L, but
> >>> how long
> >>> it take and how many errors you can do when you will investigate?
> >>
> >> It's just as bad when there's code like this:
> >>
> >> T2 = something(T),
> >> T3 = something(T2),
> >> T4 = something(T3),
> >> T5 = something(T4),
> >> T6 = something(T5)
> >>
> >> You may laugh at that code, but it's hardly uncommon, even in code
> >> written by experienced programmers.  It's very easy to accidentally
> >> use T4 in a spot when you meant T3, or to have to renumber things and
> >> make a mistake.
> >>
> >> Please note that I am not arguing for changes in Erlang.  I truly am
> >> not.  But I can understand why this request comes up regularly.
> >>
> >> James
> >
> > Erlang should not introduce mutable variables because they make it
> > easy to disguise a variety of code smells as clean code.
> >
> > Code like James' example is code that does not express its intentions
> > clearly.
>
> I disagree. Code like this:
> State1 = updateStateSomehow1(State, SomeVariable),
> State2 = updateStateSomehow2(State1, SomeOtherVariable),
> State3 = updateStateSomehow3(State2, SomeReallyOtherVariable),
>
> quite clearly expresses the intention: update the state.


Well, if you want this, do it this way:

NewStata = lists:foldl(
   fun({F, A}, S) -> F(S, A) end,
   State,
      [
         {updateStateSomehow1,SomeVariable},
         {updateStateSomehow2, SomeOtherVariable},
         {updateStateSomehow3, SomeReallyOtherVariable}
   ]).

Just refactor your code, don't break Language!


>
> [...]
> > If you give semantic names to each transformation applied to the data,
> > then the code will express its intentions clearly. When you express
> > your intentions clearly you avoid a lot of bugs. Subsequent
> > refactoring work is also made easier, especially when the original
> > author is unavailable.
>
> The problem with detailed semantic names is that they tend to be long.
> Given the ugliness of the erlang record syntax you'd soon end up with
> experssions like this:
> StateUpdatedWithSomeVariable#stateRecord.some_field
>
> instead of the intuitive
> State.some_field
>
> which is actually readable and fits on the terminal nicely, unlike the
> erlang variant.
>
>                                Bye,NAR
> --
> "Beware of bugs in the above code; I have only proved it correct, not
>  tried it."
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080727/60775d68/attachment.htm>