Recommended books to anyone aspiring to reach a mental state above the level 'it works'<div><br></div><div><a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882">http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882</a></div>
<div><a href="http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073">http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073</a></div><div><a href="http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X">http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X</a></div>
<div><a href="http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091">http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091</a></div><div><a href="http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672">http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672</a></div>
<div><br></div><div>None of them are particularly heavy (although, the last two are more for reference).</div><div><br></div><div>Professional developers try do deliver cheap code.</div><div>More time is spent reading code than writing it. </div>
<div>Therefore, minimize the time needed to read your code, making it cheaper.</div><div><br></div><div>I would happily receive more good tips on book touching the subject of mastery</div><div>and professionalism.</div><div>
<br></div><div><div class="gmail_quote">On Fri, Mar 8, 2013 at 1:01 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I've heard people say "writing code is easy" I disagree</div><div><br></div><div>1 - writing code that appears to work is easy</div><div>2 - writing code is correct is far more difficult</div><div>3 - writing code that is correct subject to the condition that is clear and</div>
<div> can be understood by other people is very difficult</div><div>4 - writing code that is correct subject to the condition that is clear and</div><div> can be understood by other people and maintained in the future and</div>
<div> modified in the future is very very difficult</div><div>5 - writing code that is correct subject to the condition that is clear and</div><div> can be understood by other people and maintained in the future and</div>
<div> modified in the future and is efficient is very very very difficult</div><div> </div><div>Writing efficient code is absolutely the last thing on my list - I get stuck</div><div>round about point 2.</div><div><br>
</div><div>About 25 years ago I wrote some code that was mind-melting complicated</div><div>the usual stuff - super smart code, super efficient, super undocumented, let the force be with you stuff</div><div><br></div><div>
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.</div>
<div><br></div><div>These days if I have an easy problem I write the code first - but if it's</div><div>tricky I write some kind of user description first.</div><div><br></div><div>I also have a rubber duck next to my computer - and the queen - in</div>
<div>tricky cases I try to explain how my code works to the rubber duck and the queen.</div><div><br></div><div>I take my rubber duck to meetings - when I just don't understand things</div><div>I pull out my rubber duck and say the magic words ...</div>
<div><br></div><div>" go on explain to the rubber duck ..."</div><div><br></div><div>Rubber ducks are pretty stupid so if the rubber duck can understand it</div><div>I can usually understand it.</div><div><br></div>
<div>If you can explain your program to a rubber duck it's probably OK</div><div><br></div><div>Cheers</div><div><br></div><div>/Joe</div><div><br></div><div> </div>
<div><br></div><br><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 5:25 PM, Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Thu, Mar 7, 2013 at 3:11 AM, 饕餮 <<a href="mailto:249505968@qq.com" target="_blank">249505968@qq.com</a>> wrote:<br>
> I wonder if Function call is better than Case when both of they can<br>
> implement the target I want?<br>
> It seems like write a function instead of case could make the code more<br>
> clear .<br>
> But which one is fast when it running?<br>
> I intend to change the case to function to make the code more clear. Is this<br>
> valuable?<br>
<br>
</div></div>Over the last year or so, I've started to adopt the approach outlined here:<br>
<br>
<a href="http://www.gar1t.com/blog/2012/06/10/solving-embarrassingly-obvious-problems-in-erlang/" target="_blank">http://www.gar1t.com/blog/2012/06/10/solving-embarrassingly-obvious-problems-in-erlang/</a><br>
<br>
There are few things I'd like to modify in a followup post [1] but the<br>
general idea of working to make your code "embarrassingly obvious"<br>
still is the central idea.<br>
<br>
Functions are the primary mode of "making things obvious". They let<br>
you take otherwise hidden or implicit logic and making it explicit.<br>
<br>
The smaller and more focused your functions, the better. You should be<br>
able to look at the function and, in just a moment, know what it does,<br>
without reading comments. If it's not that obvious, ask why, then<br>
clarify it by codifying "what's going on" in functions.<br>
<br>
At the time of writing the piece, I didn't have enough experience with<br>
this method to know whether it was Good or Not Good. Today, I believe<br>
that it's Very Good! (with amendments listed below)<br>
<br>
Here's why:<br>
<br>
- The "obviousness" standard, while subjective, drives a programmer to<br>
think carefully about *everything*, to the point of understanding the<br>
problem/solution ad nauseam<br>
<br>
- It shifts the nature of programming from "make the code work" to<br>
"say what I want to say" -- which is a shift away from brute force<br>
experimentation to deliberate problem elaboration/solving (this is why<br>
I advocate trading test time for make-your-code-obvious time)<br>
<br>
- Your left with code that's *extremely* maintainable -- neither bugs<br>
nor potential enhancements have anywhere to hide! Any change will<br>
necessarily affect a small surface area that's easy to think about<br>
(while you may see ripple effects across many functions depending on<br>
the change, you'll know the exact boundary)<br>
<br>
As to performance, I'll followup with a separate reply, as it involves<br>
large code chunks and this reply is already too long :)<br>
<br>
Garrett<br>
<br>
[1] There are a few changes I'd like to make to the religious dogma:<br>
<br>
1. RoK and others have pointed out -- and I've come to heartily agree<br>
with this -- that the use of variables can help further clarify a<br>
function by a) placing key functions on their own line, thus<br>
highlighting them, b) changing the order things are read from<br>
right-to-left (as in the case of reading function calls) to top-down,<br>
and c) a single variable name can be clearer than a function call with<br>
arguments.<br>
<br>
2. While it's possible to replace *all* case expressions with<br>
functions, there are instances where case is clearly better. The<br>
signal is when code becomes decisively *less obvious* without the case<br>
expression. It's a judgement call.<br>
<br>
3. In the blog post example, I use a pipeline to convey arguments to a<br>
function. This is very odd indeed -- arguments should be spelled out<br>
and passed discretely to a function, not as an array of values. (In<br>
fact, there's a horrible error in that code, terrible!)<br>
<br>
Note that each of these points contributed to reduced lines-of-code<br>
per function. You can see this was clearly a goal of mine!. Since<br>
then, I've relaxed the LoC per function dogma. Though it's still a<br>
good proxy for code quality, just without the authoritarian<br>
religiosity.<br>
<div><div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>