[erlang-questions] Variable naming conventions

Garrett Smith <>
Sun Apr 4 23:01:44 CEST 2010

On Sun, Apr 4, 2010 at 1:36 PM, Joe Armstrong <> wrote:
> Could this be a sign of a deeper problem?

I think so. I'm new to functional programming and am carrying over
some habits from imperative languages that are contributing to this

> I don't excited about variable names - but I do worry about
> the accuracy of function names. It seems to me that variable
> Names only become a problem when the functions (or clauses) are large.
> A very small function will have few variables and very little to get
> confused about.
> I tend to use H, T (heads and tails of lists) L (lists)
> I,J,K,N,M integers (The habits of Fortran dig deep)
> My rule is - short functions with accurate names. If the function
> is more than about 15 lines refactor it. Use short variable
> names. If this is not abundantly clear add a comment and
> a type signature and a test case.
> I actually very much prefer very short variable names -
> if I say file:open(F, [...]) I *know* F is a file since it's strongly
> signaled by the "file:..." function call - no need to say
> file:open(InFile) or whatever.

This makes sense in light of the short function requirement. I need to
get better at spotting the right factoring sooner so I'm not spending
as much time rewriting code :)

> /Joe
> On Sun, Apr 4, 2010 at 5:26 PM, Garrett Smith <> wrote:
>> I routinely run into two cases of variable naming that frustrate me.
>> I'll try to give them each a name:
>> - Variable iterations
>> - Variable leakage
>> A really common case of iteration is when process state is updated.
>> Something like this:
>>  handle_call(_, #state{name=Name}=State) ->
>>    UpdatedName = strip_white_space(Name),
>>    {noreply, State#state{name=UpdatedName)}}.
>> This isn't an awful example, but tacking "Updated" onto a variable
>> that changes just feels too arbitrary and it's too long.
>> I've tried this approach:
>>  StrippedName = strip_white_space(Name)
>> This is probably most in the spirit of Erlang's immutability naming
>> scheme -- pick good, descriptive names. But it also gets to be
>> painful. The names are long and you end up using weird abbreviations,
>> and the names become an unnecessary point of maintenance.
>> I saw the use of a "0" suffix to denote the "naught" version of a
>> variable. This seems like a nice convention: it's short, fairly
>> obvious and doesn't require a bit of hand wringing.
>> There's also something like Name1, Name2, Name3, ...
>> I've avoided this in principle because it feels like a cop-out: it's
>> probably a sign that the function needs refactoring.
>> The other frustrating case -- and far more so -- is something like this:
>>  Name = case get_name() of
>>    undefined -> "";
>>    {ok, NameValueReturnedByGetName} -> NameValueReturnedByGetName
>>  end
>> (I'm calling this "leakage" because I'd probably just call it Name if
>> it didn't leak. While that'd be clunky, it at least says what I think
>> it should.)
>> I've tried names like this: N, Val, Str, S.
>> All yuck!
>> I know I can refactor this into a function and solve the problem, but
>> of course there are cases where I don't want to. And in general, I
>> don't know if "having problems picking a variable name" is a good
>> reason for creating a function. (Maybe it is but what about cases when
>> you just don't?)
>> I'm curious what others use for these cases. Is there one convention
>> that tends to be used more frequently?
>> Garrett
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:

More information about the erlang-questions mailing list