Variable naming conventions

Garrett Smith g@REDACTED
Sun Apr 4 17:26:05 CEST 2010


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


More information about the erlang-questions mailing list