I am (like most others, I imagine) - amused by this email thread that now drifts far<div>off from the original question, and now ventures into and through the land of clean code,</div><div>good coding practices and principles.</div>
<div><br></div><div>Seriously, everyone  who has not seen the work of Robert C. Martin (Uncle Bob), is strongly encouraged</div><div>to do so. He is a very strong character who pours a lot of hours into writing and thinking about communicative</div>
<div>code, and readability.</div><div><br></div><div>Why am I writing? I just want to take the time and support the previous email, which I hope</div><div>will be the last, so we can avert a full-blown flame war between the short-variable-name and comments</div>
<div>people and those who focus on clarity, communication and conveying of intent.</div><div>No matter what smart solutions you think you have for a problem. If it is unreadable by someone else, </div><div>and not maintainable - you have failed. You clearly failed to express yourself through code.</div>
<div><br></div><div>Another thing that I have noticed is that some "old timers" believe that they do not need to educate</div><div>themselves in the art of clean coding. They only care about making it work, and stop at that. </div>
<div>It is saddening, as there are a lot of upcoming developers from younger generations that look up to </div><div>them as role models, and so, the unprofessional attitude is passed down from one generation to the next.</div>
<div><br></div><div>The professional knows that clean code that clearly communicates your intent - is the king.</div><div> </div><div>Cheers</div><div> G</div><div><br></div><div><div class="gmail_quote">On Sun, Mar 10, 2013 at 9:27 AM,  <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I once had to maintain some code written by a highly skilled<br>
programmer in a language not entirely unlike Erlang.  All the<br>
variable names were one letter or one letter and one digit.<br>
<br>
It had me screaming in frustration.  It took me about a day a<br>
page to reconstruct meaningful names for the variables.<br>
<br>
I'm trying to think of anything nastier for a programmer to<br>
do to another programmer than to know something the second<br>
programmer needs to know and deliberately choose to conceal<br>
it by using ultra-short variable names.  If I have any luck<br>
I'll let you know.<br>
<br>
Seriously, the job of a programmer is to *COMMUNICATE* with<br>
other programmers.  I wish I could offer a simple rule for<br>
how long to make variable names.  My colleague who refuses<br>
to use "i" for a loop index in C++, preferring<br>
innerLoopIndex, clearly errs on one side.  Someone who uses<br>
T for timestamp, tree, and table in the same module clearly<br>
errs on the other.<br>
<br>
One rule of thumb I can offer you is this:<br>
there's an interplay between *type* and *purpose*,<br>
in that a variable with a complicated type is likely<br>
to have few plausible purposes in a given scope.<br>
If it's obvious to a reader what the type of a variable<br>
is, you can get away with shorter variables.<br>
For something with a frequently used type, you had<br>
better be clear about purpose.<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>