Your SlideShare is downloading. ×
  • Like
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply



A short lightning talk rant on why you should use Perl::Critic as a supplemental tool to code/peer review

A short lightning talk rant on why you should use Perl::Critic as a supplemental tool to code/peer review

Published in Technology , Art & Photos
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Perl::Critic Why (and how) you should write your own Perl::Critic policies By @jonasbn for Nordic Perl Workshop 2013
  • 2. this should have been: how (and why) but…
  • 3. ENOTIME
  • 4. So this is why and not so much how
  • 5. • peer/code review is (by far IMHO) the best way to ensure quality, security and integrity of your code • exchange the word code for another term like product, deliverable, article, solution, creation aso. • Don’t you get these reviewed by your peers/ teachers/mentors/colleagues/spouse?
  • 6. • peer/code reviewing is hard work • it is time consuming (AFK time) • not always understood or accepted by managers/peers (AFK time) • but so are meetings?? • it does take you out of your comfort zone (AFK?) • non-issue for open source developers
  • 7. • The recommendation is that peer/code review sessions should not take longer that 2 hours • So lets make the most of these
  • 8. • We do not want to waste time on unnecessary details • • curly braces, indentation, tabs vs. spaces We do not want to argue over unnecessary details during the review process • anti-patterns, common idioms, coding guidelines
  • 9. • A true war story • malicious code got injected in our system as a POC by a security consultant • The problem was presented to security • The comment was that the attack was really creative • YES!
  • 10. • Coding is done by humans and it is therefor very creative • Even attacks can be very creative • Too “creative” code can be hard to test, hard to debug and hard to maintain • We need to boost creativity to identify the above pitfalls • So in order to make room for this we let the machines take care of the trivial parts
  • 11. Enter Perl::Critic
  • 12. Perl::Critic • Perl::Critic policies are document based • Perl::Critic policies are simply Perl modules implementing a required interface • Perl::Critic is based on PPI (Parse Perl Isolated or I Parse Perl in reverse)
  • 13. Tip 1 % ppidump
  • 14. % tools/ppidump '$VERSION = "0.01";'! PPI::Document! PPI::Statement! [ 1, 1, 1 ] PPI::Token::Symbol '$VERSION'! [ 1, 10, 10 ] PPI::Token::Operator '='! [ 1, 12, 12 ] PPI::Token::Quote::Double '"0.01"'! [ 1, 18, 18 ] PPI::Token::Structure ';'
  • 15. TODO • Formulate your coding guidelines • Implement Perl::Critic policies for your common anti-patterns and promoted patterns or coding style • Comply or Explain
  • 16. • Your code/peer review sessions will add more value and can focus on what is important • You can unleash creativity and identify the hard issues related to security and integrity