I've been asked to prepare some guidelines on coding standards
and code reviews in general, across a number of languages used at work,
not just Perl.
After doing a bit of basic research, I've cobbled together the notes below.
To gain some feedback, I'm posting an early draft here.

Note that language-specific coding standards are not covered here;
these will be covered in separate coding standards documents, one for each language.

Most of the coding guidelines below were not invented by me, but derived from
hopefully well-respected sources; see the Coding Standards References section
below for details.

General Guidelines

These are some general attributes you should strive for in your code.
Remember that code maintainability is paramount.

Robustness, Efficiency, Maintainability.

Scalability, Abstraction, Encapsulation.

Uniformity in the right dimension, creativity in dimensions that matter.

When in doubt, or when the choice is arbitrary, follow the common standard practice or idiom.

Don't optimize prematurely. Benchmark before you optimize. Comment why you are optimizing.

Don't pessimize prematurely.

Don't reinvent the wheel. If there is a library method that implements the functionality you need, use it.

Be const correct.

Adopt a policy of zero tolerance for warnings and errors. This principally means compiling cleanly at high warning levels, but is broader than that; for example, tools such as checked STL implementations, static code analysers (e.g. Perl::Critic, FxCop), dynamic code analysers (e.g. valgrind, Purify), unit tests (e.g. Test::More, NUnit), code that emits spurious warnings/errors in customer log files, and so on. Third party files may be exempt from this policy.

Use a revision control system.

Write the test cases before the code. When refactoring old code (with no unit tests), write unit tests before you refactor.

Add new test cases before you start debugging.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Design

Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.

Testability. Systems should be designed so that components can be easily tested in isolation.

Data hiding. Minimize the exposure of implementation details.

Minimize the use of global data.

Interfaces matter. Once an interface becomes widely used, changing it becomes practically impossible (just about anything else can be fixed in a later release).

Design the module's interface first.

Design interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience. Be sufficient, not complete; it is easier to add a new feature than to remove a mis-feature.

Maintainability/Supportability

Follow the de facto standard set by the code you are editing. Or change the entire source file to the new standard.

Remove unused code.

Assert liberally. Asserts should be used to document the constraints for a piece of code.

Log liberally. Strive to log enough information to trouble-shoot a customer problem without the need to attach a debugger.

The result of every file operation or API call or external command must be checked, and unexpected results handled.

Any unexpected result from a file operation or API call or external command should be logged.

Avoid magic numbers. Note that 0 and 1 are ok and are not considered magical.

Limit and explicitly comment case "fall throughs".

Avoid side effects. e.g. inside macros.

Layout

Layout rules will vary between organisations. These sort of arbitrary code
layout rules should be enforced by a tool (e.g. Perl::Tidy).

Use spaces not TABs.

Three character indent (four is more common; get agreement and enforce with a tool).

Remove commented-out code, unless it helps to understand the code, then clearly mark it as such.

Update comments when you change code.

Separate user versus maintainer documentation.

Include a comment block on every non-trivial method describing its purpose.

Major components should have a larger comment block describing their purpose, rationale, etc.

There should be a comment on any code that is likely to look wrong or confusing to the next person reading the code.

Every non-local named entity (function, variable, class, macro, struct, ...) should be commented.

Portability

Assume file names are case insensitive in that you cannot, in general, have two different files called fred and Fred.

Source code file names should be all lower case.

File names should only contain A-Z, a-z, 0-9, ".", "_", "-".

Strive to structure code around "capabilities" rather than specific platforms. For example, "if HAVE_SHADOW_PASSWORDS" rather than "if SOLARIS_8". And define the capabilities in one place only (e.g. config.h).

Organise the code so that machine dependent and machine independent code reside in separate files.

Abstract hardware and external interfaces in a module and have all other code call that module and not call the hardware/external interface directly.

As far as possible, write code to a widely supported portable standard (e.g. ANSI C, POSIX, ...) and only use machine specific facilities when absolutely necessary.

All command line tools should provide a usage option to explain the usage of the command. Always include at least one example in the usage description. You must at least support the -h option for help and optionally may support --help.

Provide appropriate, clear feedback to the user of the progress of any long running operations and make them easy to cancel and safely rerunnable.

These domains warrant their own section. However, both these domains can be
incredibly challenging. :-) For now, this is just a stub section.

Define the product internationalization and localization goals.

Code Reviews

The two principal types of code review are: formal and lightweight.

Formal code reviews require significant planning, training and resources; they are carried out in multiple phases by multiple participants playing various roles. The most well-known formal code review method is the Fagan inspection.

Lightweight code reviews, having less overhead than formal ones, are cheaper to conduct.
The Best Kept Secrets of Peer Code Review book argues that lightweight code reviews are cheaper to perform than formal ones and can be just as effective.
The four most common types of lightweight code review are:

Before the code review, push the code review through a tool that checks for straightforward layout and stylistic issues; this avoids wasting time on trivia during the review.

Most of the code review work should be done before the code review meeting.

The code review should be in writing.

Have at least two code reviewers.

Tool-assisted Code Review

Guido van Rossum's first project at Google was Mondrian, a code review tool.
Though he was unable to open source that work, he has since released the open source
Rietveld code review tool.
An exhaustive list of code review tools can be found at Survey of Code Review Tools.

In addition to tools that streamline the administrative side of the code review process, source code analysis tools can further be useful during code reviews. These tools fall into three broad categories:

Updated 20-feb: Added new "Design" and "Portability" sections. Updated 3-mar: Added new "Security" and "Internationalization and Localization" sections; added more General Guidelines; added more references.