[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