[erlang-questions] Variable naming conventions

[Joe Armstrong]

Could this be a sign of a deeper problem?

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.

/Joe




On Sun, Apr 4, 2010 at 5:26 PM, Garrett Smith <g@REDACTED> 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:erlang-questions-unsubscribe@REDACTED
>
>