Programming Rules and Conventions | Hacker News Reader

Programming Rules and Conventions

erlang.se

39 pointsfogus16 comments

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

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?

> 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.

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.

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

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.

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.

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.

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

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

Why not program defensively?

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.

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

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.

It depends on the scenario. Web services or user interfaces accepting user input should be validated. However, in deeper code, it is better to let the system throw an exception and let the client handle it. Otherwise, how would the client know the method failed? Also, it is easier to debug behavior if a system throws an exception, rather than hiding the error.

You should...at the inputs to your system. Check the data when it enters your control. After it enters your code it's almost always possible to statically ensure that the data meets your invariants (hopefully they're well documented). Thus, programming defensively at this point doesn't do anything but slow the system down by adding redundant checks.

Reply on news.ycombinator.com