Mike Kruckenberg

« The Traditional Conference Music Purchase | Main | Time Management for System Administrators »

July 26, 2004

Best Practice Perl

First presentation of OSCON 2004 is Damian Conway, giving a tutorial titled "Best Practice Perl." There is a good handout of the slides that details things, but Damian goes into futher detail on each slide, want to catch some of that. Not sure I'll catch everything Damian is saying, but at least the highlights.

Damian Conway not coming off the mountain to give us the 10 Commandments of perl (shows picture of Charlton Heston). There is not one best way to do most things, it changes between people. Rather than "the" best practice, these are "a" best practice. Learn to avoid IPS (Intuitive Programmer Syndrome), coding to feel good, as opposed to doing what's best. This presentation is a start, best practices need to be agreed apon by all team members, who must stick to it. Giving up IPS is difficult, like giving up smoking . . . . crack.

One of the overlying goals is to make code instantly recognizable. We shouldn't write from a writers point of view but a reader and comprehension point of view. Best practices are sometimes writing good code that works, but often can also be rules for coding that it will make it easy to find something stupid we've done.

General Thoughts

• natural enemy to the coder is the if statement, avoid if you can, readability suffers with each if condition
• writing code is not writing literature to be admired as a great work in the future, is to be comprehensible so keep it straightforward
• don't trust what Damian says or your intuition, trust the benchmark
• people are great at not following rules they don't like
• whenever your brain tells you something you programmed is "cool" it's probably a sign that it might not be readable or work in all cases - cool, clever, magic code is scary in production

Layout Style

Layout style (K&R, DSB, GNU, Slash) doesn't matter, all are equally false. Agree on how to space etc.

• semi colon after every statement, even last
• 4-column tab (the stones Moses brought down with the 10 commandments were 4-column tabbed)
• verticial alignment is key, especially in like items (hash definitions)
• code in paragraphs, component by component, each with a comment

Identifyers

Have a consistent style of naming identifiers.

• avoid intercaps, we're used to reading words with spaces
• shorten words by abbreviation, not by removing vowels
• name hashes in singular, arrays in plural
• use a grammatical tempate
• names should tell us about use

Variables

• avoid using punctuation and package variable where you can, use lexicals
• use local variables
• $_ is OK as long as you don't have to refer to it explicitly in code, but must remember is almost always an alias to another variable
• always use my when declaring a lexical for a loop (for my $item (@items))

Control Structures

• use block-scoped control, not statement-scoped
• avoid C-like for statements
• use for my $val (values %hash) and can set $val = x and change hash
• use Lexical::Alias
• when you've got 5 or more lines that you have to keep looking at and having to understand create a sub
• List::Util provides some good functionality that might make it easy to avoid
• map is always faster, because it's in C - use it for generating new list from old
• using a for list with push has to reallocate
• use for loop when you need to change a value in an array
• use tabled ternary operators instead of if statements - forces the last else
• do not use Switch module in production code - works 99 of 100 times

Documentation

• for every 1 minute spent on development, 100 minutes spent in maintenance
• is the lifeline maintenance
• create a POD template, then cut and paste
• put POD after __END__ - parser doesn't have to parse and POD doesn't have to follow the layout of the code
• external document tells what job the code does, internal documentation tells how the code does it's job
• comments are love notes that you are sending to your future self
• if you have to explain something might want to consider if it can be done in a way that would require less explanation
• Damian confesses that he has modules that aren't properly documented (currently IO::Prompt), but that he never releases them for use until the documentation is completed

Halftime break - Damian shows a slide show of "friendly animals," a presentation about spiders, snakes, bugs etc in Australia that are all deadly - quite funny - a song by Scared Weird Little Guys about dangers of Australia

Built in Functions

• use the values function for hashes
• use a block for map and grep
• use non-builtin builtins like List::Util and Scalar::Util

Subroutines

• always unpack @_, no value in using $_[1]
• pass in named arguments to subs ("name"=>"Mike"), don't have to know order and can be tested
• if want to pass in unnamed args have the last arg be a hashref, not a list of named args - makes it so the hash is created by caller so a failure is easy to find and fix
• avoid prototypes
• always use and explicit return, do not fall off the end
• always explicitly do return scalar when a scalar is expected as a return
• do not return undef, in a list context undef is 1 value

I/O

• don't use bareword filehandles, can be clobbered, create a lexical
• use three-argument open, two-arg can cause sublte failures
• use {$file} brackets around lexical filehandle variable to make it easier to read
• Always prompt if the stdin and stdout are both terminal, use IO::Prompt (not yet released)

Regex

• always use the x flag for extended, broken onto separate lines with comments
• use /m to make $ and ^ work naturally
• never use $ and ^ as string boundary, use \A and \Z
• use /s so the . will match a newline
• use Regexp::Auto which automatically turn /xms mode on in every regex
• only use (...) when intentionally capturing, use (?:...) to indicate that you're not capturing
• don't use $1,$2,$3 - immmediately name them something meaningful
• build up large regex from simple pieces - use qr{...}x to build pieces assigning to variables - only put capturing parens into lowest last fragment
• factor out the common parts at beginning and end, only use the regex for the exact part you want to match - means regex doesn't have to check common pieces over and over
• use ?> to tell engine to not backtrack uselessly

Errors

• prefer exceptions to special return values

Posted by mike at July 26, 2004 9:45 AM

Hard Drive Recovery Group offers hard disk data recovery services for RAID, laptops and servers. Complete clean room and hard drive repair service.

Trackback Pings

TrackBack URL for this entry:
http://mike.kruckenberg.com/mt/mt-tb.cgi/37