Giacomo Vacca

Browsing StackOverflow on perl-related topics, I have two main considerations: 1. Answers are typically very good, concise and useful 2. Questions are submitted with code that doesn't have 'warnings' enabled I'd say that a considerable portion of the questions submitted would not be posted, or would be less generic, if authors used 'use warnings;' in their code. Then add a pinch of the great perl critic , and possibly only half of the questions would really be submitted. If you're using perl, or plan to use it, I strongly recommend to: 1. Always set 'use warnings;' 2. Always submit your code to perl critic (and keep a copy of Perl Best Practices handy). 3. First create the tests, then write the code. That's the only reasonable way (unless you're working on a one-liner for a quick admin task). TDD is your friend . See more on Perl Critic here .

When I’ve found Inside-Out Objects not only mentioned but suggested inside Perl Best Practices (see "Always Use Fully Encapsulated Objects" section) I thought: “Cool, here’s a solution to enforce encapsulation on Perl classes. This was badly needed”. But then, the list of advantages wasn’t too exciting, while the drawbacks were quite scary… See for example this analysis . To simplify the problem, note that all I want is: “a mechanism to prevent an object attribute to be read or changed from outside the object”. In Java, C++, PHP, you just declare that class attribute as private . Simple. (Python has a form of “privatization by obfuscation” that I don’t really like, but it may be better than what Perl does – which is nothing). Perl (5) is not a full OO programming language, just a procedural language that has got some additions to allow for OO dynamics, but still I'm surprised I can't "protect" object attributes... Getting back to Inside-Out Objects, t...

perlcritic is "a static source code analysis engine", a CPAN module which can also be used as a command . An example: $ perlcritic -severity 3 src/AModule.pm Subroutine does not end with "return" at line 24, column 1. See page 197 of PBP. (Severity: 4) Return value of eval not tested. at line 32, column 5. You can't depend upon the value of $@/$EVAL_ERROR to tell whether an eval failed.. (Severity: 3) As you can see you can get extremely useful information about the sanity of your code and how much it complies to good coding practices. There are 5 different severity levels (being 5 the "less critic"). Most Policy modules are based on Damian Conway's book Perl Best Practices ( PBP ), but it's not limited to it. I run perlcritic (using typically severity 3) automatically on all the source code files, every time I run the unit tests and/or build a package, in order to get as soon as possible a valuable feedback after code changes. Since the ...