[erlang-questions] Hungarian notation for Erlang / ETL

[Richard Carlsson]

Zvi wrote:
> Is there some kind of Hungarian notation for Erlang? i.e. prefix or postfix
> naming convention.
> As Erlang has dynamic typing and somewhat confuzed about string datatype, I
> constantly make errors when mixing lists and binary strings. This is
> reminding me situation when programming C++ for Win32, where you have
> zero-terminated, STL, MFC, BSTR and other string representations.
> I saw atleast one .erl sorce code, where the author using "B" postfix  for
> binaries, i.e. Query - is query string list, but QueryB - is query string

In general, Hungarian notation is a very bad idea. The reason is that
it is actually a *comment*, which tries to remind you about what type of
value a variable should be bound to. But as all comments, they rot. So
after some time, as representations get changed, a programmer (let's
assume it's not you, but someone else, two years from now) either has to
rename all variables (not likely), or live with the misleading names
(sucks). Basically: never, ever, use names that refer to implementation
details which may change, such as types.

To reduce confusion, write down your assumptions about types etc. in
comments above at least the main functions (preferably, use edoc).

However, you might well use conventions for *roles*. For example, in
C/C++, people often include a 'p' to indicate a pointer variable. This
is not just a type indicator, because with pointers you need to use
explicit dereferencing - they have to be handled differently from plain
values. Hence, if you change something from a pointer to a nonpointer,
you would be rewriting your program anyway, so renaming the variables
is not such a big deal. But there seems to be few such naming
conventions in Erlang programs. (There are of course conventions, but
not very systematic ones; mostly things like including 'Pid' in a name
if it is supposed to be a process identifier - this may be motivated by
the same reasoning as for pointers in C.)

Furthermore, as Dominic noted, when you write your programs using names
that do not say too much about what they are supposed to be, you tend
to realize much easier that pieces of your code are actually much more
general, and can be lifted out to separate, polymorphic functions.

I agree that it would be nice with some more general functions for
working on "collections" and "strings" in general, similar to the STL,
but currently there is no such library (and it would incur some
overhead). It is however easy to write an abstraction layer for those
datatypes like tables, strings, etc., so that you can change
implementations more easily if you think it might become necessary.

     /Richard