Erlang Programming Rules now a dead link

There used to be a “Programming Rules” page where it talked at length about why defensive programming is a bad idea, but that link is now dead.

Now, the closest thing I find is from the FAQ: 10.23 I’ve heard it’s a bad idea to program defensively in Erlang. Why? (which contains a reference to said page)

Was the removal of this page intentional? And if so, is that FAQ the closest I’m going to get an authoritative reference when making an internal list of grievances about our code?

3 Likes

There is a copy over at Programming Rules but i’m wondering if the ERLEF education working group should host this? CC @peerst

6 Likes

FWIW, there is also GitHub - inaka/erlang_guidelines: Inaka's Erlang Coding Guidelines
I mean… just in case you’re looking for list of grievances validation :roll_eyes:

5 Likes

The recommendation there for 100-character lines is a poor choice.
Even 80-character lines are eye-wateringly long.
I do have a project where there’s a 221-character line,
but (a) that’s machine-generated code not intended for
people to edit and (b) I’m in the middle of rewriting the
generator to not do that (some lines are still excessively
long but that one’s gone).

There is a reason newspapers use narrow columns.
A typical paperback, meant for comfortable reading,
might have 65 characters per line.

So I would recommend keeping lines no longer than 65
characters if you can without making your code ugly in
other way, except for machine-generated code that
people are not supposed to see.

1 Like

…and that’s why Elvis / rebar3_lint is configurable in that regard! :slightly_smiling_face:

2 Likes