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

饕餮 249505968@REDACTED
Sat Mar 9 03:21:05 CET 2013


Thanks Gianfranco,
The books seems great!
I've read some of it.Clear code would be the most important thing in my work!

I'm not sure how to reply the mail via mail list (It's my first time to use mail list system).
Thanks all others who help me how to make code more clear!






------------------ 原始邮件 ------------------
发件人: "Gianfranco Alongi"<gianfranco.alongi@REDACTED>;
发送时间: 2013年3月8日(星期五) 晚上8:54
收件人: "Joe Armstrong"<erlang@REDACTED>; 
抄送: "Garrett Smith"<g@REDACTED>; "饕餮"<249505968@REDACTED>; "erlang-questions"<erlang-questions@REDACTED>; 
主题: Re: [erlang-questions] Which choice is better? Function or Case



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/20130309/f38822af/attachment.htm>


More information about the erlang-questions mailing list