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.
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
> 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.
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.
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.
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.
16 comments
[ 3.2 ms ] story [ 38.6 ms ] threadIf 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.
Also the seasoned Erlang programmer will find it useful.
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?
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.
For the most part though, my comment stands, and it is, indeed one of the more unique and charming aspects of erlang.
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.