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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply



Published on

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

1 Like
  • 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