[erlang-questions] Variable naming conventions

[Garrett Smith]

On Sun, Apr 4, 2010 at 12:05 PM, Eric Merritt <ericbmerritt@REDACTED> wrote:
> Garrett,
>
>  You have already mention most of the approaches to solving this problem.
>
>> 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)
>
> I usually wouldn't have an intermediate variable here.  I usually end
> up with something like.
>
> handle_call(_, #state{name = Name} = State) ->
>     {noreply, State#state{name = strip_white_space(Name))}}.

Yeah, I generally would as well, but for the example. Though, as you
illustrate below, breaking calls out into separate assignments can
help readability, IMO.

>
> basically passing the returned value of a 'thing' directly into the
> next 'thing' you are going to call. This is the most common approach
> in the code I write, I also think its pretty common in Erlang code in
> general.
>
>
>> 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, ...
>
> This is also very common. You could say the names aren't tremendously
> descriptive, but the function calls themselves tend to be. For an
> arbitrary example.
>
> do_some_mangling(Somewhere) ->
>  Name = get_some_initial_values_from(Somewhere),
>  Name1 = mangle_those_values_as_a_first_pass(Name),
>  Name2 = mangle_them_in_some_different_way(Name1),
>  return_them_as_a_final_mangle(Name2).
>
> Of course, the function names aren't usually quite this verbose, they
> are usually fairly descriptive. So while you could argue that Name,
> Name1, Name2 aren't really providing that much information. The
> function as a whole is still very readable and its still very
> understandable whats going on.

Good. I'm going to starting using this where it makes sense.

>> I've avoided this in principle because it feels like a cop-out: it's
>> probably a sign that the function needs refactoring.
>
> Often, but not always. take the above example. We could place each
> function call inside the parameter list of the next call. However,
> that would probably be less readable then the example above. In
> general though, when you see this. You should probably take a good
> hard look at your code and make sure your factoring is good.
>
>>
>> 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 don't see this as a tremendous problem. Functions tend to be pretty
> short and specific in Erlang, that dramatically reduces the kind of
> collision you that this is intended to solve. I can't say that I run
> into this problem very frequently at all. On the rare occasion that I
> do a slightly longer name suffices without too much pain.

Yes, after posting the original email, I tackled the block of code
that was annoying me, refactoring into a couple of meaningful, cogent
functions and am much happier.

>
>>
>> I've tried names like this: N, Val, Str, S.
>
> Ugh, I would stay away from those if at all possible. Much better a
> verbose name then something that offers little or no information.
>
>>
>> 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 don't think so. As you alluded to before, this kind of problem is a
> bad 'smell' it usually means you need to think about refactoring your
> function. I wouldn't, however, refactor them with variable names in
> mind. I would look at the problem you are trying to solve and the
> 'actions' you are taking in your code and refactor along those lines.
> I suspect very strongly that if you do that your naming problems will
> go away or be vastly reduced as well.
>

Thanks!