[erlang-questions] how to make beautifulll code of this working code

[Roelof Wobben]

Op 11-8-2015 om 14:07 schreef ok@REDACTED:
> You wrote:
>
>>      Error checking is not needed here.
> An étude that tells you not to worry about error checking
> is an étude that is TEACHING YOU TO FAIL.
>
> Just the other day I ran into a commercial product that failed
> to validate formats for timestamps.  I am *SICK* of programs
> that don't quite work (like the Apple Mail program where the
> Search facility stopped working for me nearly a year ago, and
> where I have to reboot the machine every couple of weeks because
> Mail goes offline for no apparent reason and won't go online
> again.)  More than that, I am *FED UP* with the habit of mind
> that says "error checking is not needed here."
>
> So you solved the étude.  And then you wanted to make it
> beautiful.  Always producing good output is a major part of
> beautiful behaviour.  The étude doesn't say that beauty is
> needed either.
>
>>      <br>
>>      Here is the text of the etude I try to solve :<br>
>>      <br>
>>      <p id="write_a_module__id2">Write a module named <code
>>          class="literal">dates</code> that contains a function <code
>>          class="literal">date_parts/1</code>,
> Right there is a bad idea.  If the key term "date" is in the module
> name, it shouldn't be repeated in the function name, at least not in
> a language where the standard practice is to always write the module
> name.
>      date:parts("...")
> reads better than
>      dates:date_parts("...").
>
>> which takes a string in ISO
>>        date format (<code class="literal">"yyyy-mm-dd"</code>)
> Ah hah!  It *is* ISO8601 format that's required, and while
> *this* text says the ISO format is yyyy-mm-dd, that's not
> exactly what *ISO8601* says.  The "basic format" is yyyymmdd
> with no separators.  The version with dashes is the "extended
> format".  There are some "reduced precision" dates that cannot
> be expressed in the "extended" form, and the text of the standard
> seems to make the digits-only "basic" form the preferred form.
>
> In any case, your code does NOT check for there being four
> "year" digits, or two "month" digits ("2015-08-11" conforms
> to ISO8601 but "2015"-8-11" does not), or two "day" digits.
>
>>      and
>>        returns a list of integers in the form <code class="literal">[yyyy,
>>          mm, dd]</code>.
> And this is bad practice.  A list should be used when there is a
> varying number of things with the same meaning.  When you have a
> fixed number of items, and especially when they have different
> meanings, a tuple is appropriate.  {Y,M,D} is ok; {date,Y,M,D} is
> better.
>
>> This function does not need to do any error
>>        checking.</p>
> Only in a fantasy world.  The thing is, you *are* doing some error
> checking: if there are not exactly two dashes in the input your
> function will crash.  It seems silly to check *that* and nothing
> else.  If you *really* weren't doing any error checking you
> would do
>      [list_to_integer(Field) || Field <- re:split(...)].
>
>>      <p id="youll_use_the_">You’ll use the <code
>> class="literal">re:split/3</code>
>>        function from Erlang’s regular expression (<code
>> class="literal">re</code>)
>>        module to accomplish the task.
> If you really wanted to solve this problem, re:split would not
> be the preferred way to do it.  You'd write something like
>
> parse_date(L) ->
>      {Y,"-"++L1} = digits(4, L),
>      {M,"-"++L2} = digits(2, L1),
>      {D,""}      = digits(2, L2),
>      if 1900 < Y, Y < 2100, 0 < M, M < 13, 0 < D, D < 32 ->
>         {date,Y,M,D}
>      end.
>
> digits(N, L) ->
>      digits(N, 0, L).
>
> digits(0, A, L) ->
>      {A, L};
> digits(N, A, [C|L]) when $0 <= C, C <= $9 ->
>      digits(N-1, A*10+(C-$0), L).
>
> It appears that the étude is NOT an exercise in
> processing dates (for which it trains you to do bad things)
> but a pretext to use re:split, and a much cleaner pretext
> could have been found.
>
> In this case, for example, regular expressions *can* be used
> to good effect to match dates well, but re:split *cannot* be
> used as other than a fairly disgusting hack.
>
>> How, you may ask, does that
>>        function work? Ask Erlang! The command <code class="literal">erl
>>          -man re</code> will give you the online documentation for the
>> <code
>>          class="literal">re</code> module.<br>
> Which does *not*, in fact, explain how re:split *works*.
>
>
>

Thanks for the feedback.
I will try again to make this work with the help of your comments and 
with error checking.
I get more and more the feeling that etudes are not the right exercises 
to work on for learning good erlang.
Maybe I can better go back to programming erlang and do the exercises of 
that book and google for better exercises.

Roelof


---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus