

Programming Rules and Conventions - fogus
http://www.erlang.se/doc/programming_rules.shtml

======
peteretep
Although the examples are in Erlang, none of this seems particularly Erlang-
specific

~~~
banachtarski
This isn't true.

For example:

3.13 Do not program "defensively" suggests that the programmer should allow
functions to crash if given unhandled input types. This does not work in
_most_ other programming languages to create a fault tolerant application.

A number of advice points about process/module organization also do not apply
to most languages.

Tagging messages? Makes sense in lisp (and a few others), but again, not in
most languages

Not to trap exits, again Erlang specific.

I could go on and on. Did you even read this?

~~~
tbe
> 3.13 Do not program "defensively" suggests that the programmer should allow
> functions to crash if given unhandled input types. This does not work in
> most other programming languages to create a fault tolerant application.

Incidentally, this applies to languages with exceptions as well. The hardest
to catch bugs are when bad behaviour is hidden inside a too general try/catch.

> Not to trap exits, again Erlang specific.

Yes.

------
jlouis
This reference is full of sound advice for the new Erlang programmer. If you
break it, you need to have a good reason to do so.

Also the seasoned Erlang programmer will find it useful.

------
jweir
_Don't allow private data structure to "leak" out of a module_ offers a great
example in module, type, or even class design.

~~~
adrianmsmith
I saw this, and was reminded that OO languages have language constructs to
enforce this, i.e. the "private" keyword.

If you want to make something private (e.g. your internal implementation) it's
better to make it private (resulting in an error if someone accesses it) than
to make it public, and write a rule in section 3.11 of a convention document
and hope everyone using your code has read it and obeys it.

~~~
qu4z-2
Except that the rule there is equally applicable to OO languages, and is more
about what you should and shouldn't expose in your interface.

------
loup-vaillant
_3.1 Export as few functions as possible from a module_ — _3.2 Try to reduce
intermodule dependencies_

At last a coding convention guide that deals with something other than
_syntax_. And at the very beginning to boot. If I ever have a say to such
things at work, I'm going to take some inspiration from that.

------
informatimago
How good can a programming language with such a long and complex programming
rules and conventions book be?

~~~
vemv
In fact many of the listed practices are common to all programming languages.

------
vemv
Why not program defensively?

~~~
banachtarski
This is a basic tenet of erlang. The philosophy is that if the inputs are bad,
don't try to handle it. Crash the process to isolate the issue from the rest
of the system (and god forbid, your database). Erlang's supervisor trees will
restart the process for you.

~~~
vemv
Well that was unexpected! It makes me curious about the Erlang way. Thanks for
the reply.

~~~
banachtarski
One of the other comments mentions validating user inputs which makes sense
and is an exception to my comment above.

For the most part though, my comment stands, and it is, indeed one of the more
unique and charming aspects of erlang.

