Perl style guide

This is how I like my code, in no specific order. :)

4 space indents
No tabs in code (includes indents)
Always Class->method, never method Class (this includes "new"!)
Cuddled else: } else {
Opening curly on the same line as the keyword it belongs to
Closing vertically aligned with that keyword
Space after comma or semi-colon, but not before
No extra spaces around or inside parens: foo, (bar, baz), quux
Extra spaces in arrayref constructor: [ foo, bar ]
Extra spaces in hashref constructor: { foo => bar }
Extra spaces in code delimiting curlies: sort { $a <=> $b } @foo
No $a or $b except when sorting
No parens unless needed for clarity
Space between special keyword and its arguments: if (...) { ... }
No space between keyword and its arguments if the "looks like a function, therefor it is a function" rule applies: print((split)[22]), not print ((split)[22]). (And of course not print (split)[22])
No subroutine prototypes if they're ignored anyway
No subroutine prototypes just to hint the number of arguments
Prototypes enforce context, so use them only if that makes sense
No globals when access from another package is not needed
use strict and -w. Loading of normal modules comes after loading strict.
Lots of modules, but not to replace few-liners or simple regexes
Comments on code lines have two spaces before and one after the # symbol
No double spaces except for vertical alignment and comments
Only && || ! where parens would be needed with and or not
No double empty lines
Empty line between logical code chunks
Explicit returns from subs
Guards (return if ...) are nicer than large else-blocks
No space between array/hash and index/key: $foo[0], $foo{bar}
No quotes for simple literal hash keys
Space around index/key if it is complex: $foo{ $bar{baz}{bar} }
Long lines: indent according to parens, but always 4 spaces (or [], {}, etc)
Long lines: continuing lines are indented
Long lines: Lines begin with operator, unless it's || && and or
No "outdent"s
No half indents
No double indents
grep EXPR and map EXPR when BLOCK is not needed
Logical order in comparisons: $foo == 4, but never 4 == $foo
English identifiers
Not the English.pm module
Multi-word identifiers have no separation, or are separated by underscores
Lowercase identifiers, but uppercase for constants
Whatever tool is useful: no OO when it does not make sense
It's okay to import symbols
No here-documents, but multi-line q/qq. Even repeated prints are better :) (Okay, here-docs can be used when they're far away from code that contains any logic. Code MUST NOT break when (un)indented.)
Always check return values where they are important
No spaces around: -> **
Spaces around: =~ !~ * / % + - . << >> comparison_ops & | ^ && || ?: assignment_ops => and or xor
Spaces or no spaces, depending on complexity: .. ... x
No space after, unless complex: ~ u+ u-
Long lines: break between method calls, -> comes first on a line, space after it
=> where it makes sense
qw where useful
qw when importing, but '' when specifying pragma behaviour
() for empty list, not qw()
-> to dereference, where possible
No abbreviations (acronyms are okay, and so are VERY common abbreviations) NEVER "ary"
Data type not represented in variable name: %foo and @foo, but not %foo_hash or @foo_array
Sometimes: data type of referent in reference variable names: $bla_hash is okay
Sometimes: data type 'reference' in reference variable names: $hashref is okay
No one-letter variable names, unless $i or alike
$i is a(n index) counter
Dummy variables can be called foo, bar, baz, quux or just dummy
Taint mode *only* for setuid programs
No sub main(), unless it needs to be called more often than once
Subs before main code!
Declare variables on first use, not before (unless required)
\cM > \x0d > \015. \r only where it makes sense as carriage return.
Complex regexes get /x
No space between ++/-- and the variable
List assignment for parameters/arguments, not lots of shifts
Only shift $self from @_ if @_ is used elsewhere in the sub
Direct @_ access is okay in very short subs
No eval STRING if not needed
Constructor "new" does not clone. Only handles a *class* as $_[0]
Constructor that clones is called "clone"
Constructor can be something else than "new", but "new" is an alias
No setting of $| when it is not needed
Lexical filehandles
No v-strings
Single quotes when double-quote features not used
In DBI: value interpolation using placeholders only
use base 'BaseClass' instead of use BaseClass and setting @ISA
Comments where code is unclear
Comments usually explain the WHY, not the HOW
POD at the bottom, not top, not interleaved
Sane variable scopes
No local, except for perlvar vars
No C-style loop for skipless iteration
No looping over indexes if only the element is used
80 characters width. It's okay to give up some whitespace
Unbalanced custom delimiters are not metacharacters and not alphanumeric
RHS of complex s///e is delimited by {}
Favourite custom delimiter is []
Semi-colon only left out for implicit return or in single-statement block
No $&, $` or $'
Localization of globals if they're to be changed (local $_ often avoids weird bugs)
Semi-colon not on its own line
(in|de)crement in void context is post(in|de)crement
No map or grep in void context
? and : begin lines in complex expressions
True and false are always implied. No $foo == 0 when testing for truth.
Only constructors return $self. Accessor methods never do this.
Stacking methods is okay, but a non-constructor method should never return $self.
Accessor methods should behave like variables (Attribute::Property!)
Other methods should behave like subroutines
our $VERSION, not use vars qw($VERSION);
Module version numbers are ^\d+\.\d\d\z
Error checking is done using or. This means open or do { ... } instead of unless (open) { ... } when handling the error is more than a simple statement.
The result of the modulus operator (%) has no useful boolean meaning (it is reversed), so explicit == 0 should be used.