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

Fri Mar 8 13:54:19 CET 2013

Recommended books to anyone aspiring to reach a mental state above the
level 'it works'

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X
http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091
http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

None of them are particularly heavy (although, the last two are more for
reference).

Professional developers try do deliver cheap code.
More time is spent reading code than writing it.
Therefore, minimize the time needed to read your code, making it cheaper.

I would happily receive more good tips on book touching the subject of
mastery
and professionalism.

On Fri, Mar 8, 2013 at 1:01 PM, Joe Armstrong <erlang@REDACTED> wrote:

> I've heard people say "writing code is easy" I disagree
>
> 1 - writing code that appears to work is easy
> 2 - writing code is correct is far more difficult
> 3 - writing code that is correct subject to the condition that is clear and
>      can be understood by other people is very difficult
> 4 - writing code that is correct subject to the condition that is clear and
>      can be understood by other people and maintained in the future and
>      modified in the future is very very difficult
> 5 - writing code that is correct subject to the condition that is clear and
>      can be understood by other people and maintained in the future and
>      modified in the future and is efficient is very very very difficult
>
> Writing efficient code is absolutely the last thing on my list - I get
> stuck
> round about point 2.
>
> About 25 years ago I wrote some code that was mind-melting complicated
> the usual stuff - super smart code, super efficient, super undocumented,
> let the force be with you stuff
>
> I distributed the program. Two months later I got a bug to fix. I couldn't
> understand the code I had written two moths earlier - it was
> totally incomprehensible - I rewrote it *clearly* - it was faster - I
> modified it several times in the future - It might still be running today.
>
> These days if I have an easy problem I write the code first - but if it's
> tricky I write some kind of user description first.
>
> I also have a rubber duck next to my computer - and the queen - in
> tricky cases I try to explain how my code works to the rubber duck and the
> queen.
>
> I take my rubber duck to meetings - when I just don't understand things
> I pull out my rubber duck and say the magic words ...
>
> " go on explain to the rubber duck ..."
>
> Rubber ducks are pretty stupid so if the rubber duck can understand it
> I can usually understand it.
>
> If you can explain your program to a rubber duck it's probably OK
>
> Cheers
>
> /Joe
>
>
>
>
>
> On Thu, Mar 7, 2013 at 5:25 PM, Garrett Smith <g@REDACTED> wrote:
>
>> 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.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130308/65d5d538/attachment.htm>