Skip to main content

Posts

Showing posts with the label perlcritic

Use the Warnings, Luke

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 .

Need some constructive criticism on your code? Ask perlcritic.

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