<p>I would go so far to say that every programmer in the world would like to name things appropriately. But finding the right names can be hard and time consuming. And it is this time that is required for good naming that is often sacrificed by *managers* who are unwilling to understand the impact of poor naming. A good review structure will quite easily rectify naming deficiencies. Getting (or making) time for proper reviews is a big challenge in almost all organisations that write programs (this includes open source efforts).</p>

<p>There is one class of program where this is not a problem: use-once programs. But unfortunately, these have a habit of surviving attempts to destroy them.</p>
<p>Robby<br></p>
<div class="gmail_quote">On Mar 10, 2013 3:33 PM, "Thomas Allen" <<a href="mailto:thomas@oinksoft.com">thomas@oinksoft.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3/10/13 4:27 AM, <a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a> wrote:> 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>
I agree with this, to a point. Few things irk me as much as<br>
<br>
    Ret = fish_bowl:boil(Bowl, timer:minutes(3)),<br>
    %% ...<br>
    Ret.<br>
<br>
I've seen many high quality projects that do this, so I cannot criticize the technique as some engineering downfall, but never once have I encountered a variable of this sort that was not better served by a descriptive name. In this case, perhaps `Boiled' is the correct name.<br>

<br>
However, this has more to do with variable names that mean nothing in context. There's no sense in proscribing short variable names without consideration.<br>
<br>
Suppose a function that searches a list of `dict()`s which are expected to simply store `term()`s for the user, where we cannot infer the type or other nature of the value. In that function, I believe that variable names such `K' and `V' are entirely suitable, just as `X' and `N' fit comfortably in a mathematical function.<br>

<br>
What I don't like is variable names like `X', `X1', `X2' in a function that is not mathematical at all. Even if a program is full of nothing but the simplest functions, their clauses must still be maintained by somebody, and there's no sense in deliberately providing vague, short variable names simply for the sake of narrower code or less typing.<br>

<br>
Of course, there are exceptions to every rule ... "A foolish consistency is the hobgoblin of little minds."<br>
<br>
Thomas Allen<br>
______________________________<u></u>_________________<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/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div>