3 ms·
Programming Rules and Conventions
- jweir 14y agoDon't allow private data structure to "leak" out of a module offers a great example in module, type, or even class design.
- adrianmsmith 14y agoI 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 14y agoExcept that the rule there is equally applicable to OO languages, and is more about what you should and shouldn't expose in your interface.
- jlouis 14y agoThis 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.
- peteretep 14y agoAlthough the examples are in Erlang, none of this seems particularly Erlang-specific
- banachtarski 14y agoThis 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 14y ago> 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.
- vemv 14y agoWhy not program defensively?
- banachtarski 14y agoThis 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 14y agoWell that was unexpected! It makes me curious about the Erlang way. Thanks for the reply.
- banachtarski 14y agoOne 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.
- rcirka 14y agoIt 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.
- koenigdavidmj 14y agoYou 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.
- informatimago 14y agoHow good can a programming language with such a long and complex programming rules and conventions book be?
- vemv 14y agoIn fact many of the listed practices are common to all programming languages.
- loup-vaillant 14y ago3.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.