[erlang-questions] Variable naming conventions

[Robert Virding]

I agree Joe, though I probably have short function names than you do.
I also find that having short variable tends to make the code more
readable.

Using indexes on names is a very good way of indicating that this
references some data which flows through the function and may have
been updated, for example State0, State1, ..., or as I would probably
write it: St0, St1, ... . If you use it when the variables are not
connected then you are asking for trouble.

This is sort of my take on overlong and over descriptive variable, and
function, names:

http://www.geekherocomic.com/2008/11/12/real-programmers-dont-write-documentation/

Robert

On 4 April 2010 20:36, Joe Armstrong <erlang@REDACTED> wrote:
> 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
>>
>>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>