Great post! Here's the list I like to use:

General

• use config instead of code whenever possible
• DRY - don’t repeat yourself; use VF components, JS & Apex utilities and subroutines, etc.
• provide useful and complete documentation - field description / help text, Apex classes & methods, JS, etc.
• use descriptive names for objects, fields, classes, properties, variables, etc.

Config

• General standards above
• make custom objects and fields as restrictive as possible (required, unique, limited size, validation, precision, etc.)
• prevent duplicates using unique or validation rules
• normalize (no duplicate fields; delete unused fields)
• use camel case names with spaces between words (underscores in API names)
• add Apex unit tests to test config where appropriate

Apex

• General standards above
• no SOQL, DML, or @future calls inside loops
• bulkify all trigger and asynchronous code
• handle all potential errors; comment cases where errors should be ignored
• use asynchronous (future, batch, scheduled) when possible
• no hard-coded Ids
• when querying large data sets, use a SOQL “for” loop
• create at most one trigger per object
• use centralized trigger processing (ITrigger pattern)
• use static queries, binding variables or escapeSingleQuotes to prevent SOQL injection attacks
• clearly separate concerns (model / controller / trigger handler / view / tests)
• use custom settings for constants and configurable settings
• avoid text; use custom labels; use final properties
• avoid hard-coded date, time, number, currency formats
• when a group of fields is specified, use a field set
• follow Java coding conventions (for the most part)
• use spaces instead of tabs
• use whitespace to improve readability
• CamelCase classes, ICamelCase interfaces, camelCase methods, properties, and variables, ALL_CAP finals

Unit Testing

• General standards above
• assert proper behaviors
• test conditionals, valid inputs, invalid inputs
• always runAs a specific user
• write each test for multiple records
• don’t rely on existing data
• 100% unit test coverage

Visual Force

• General standards above
• move CSS and Javascript to static resources
• include Javascript at the bottom of the page
• use transient properties, read-only pages, and caching when possible

In addition to Salesforce's best practices and standards, there are lots of general software engineering practices you should be aware of. In my experience, some of the most important are:

• Design for testability
• Address each potential error
• DRY principal (don't repeat yourself)

I've got several articles (http://force-code.com/reviews-improve-quality-and-supercharge-your-team/), example reviews (http://force-code.com/code-review-1-salesforce/), and a book (http://force-code.com/salesforce-defect-domination-a-handbook-for-finding-fixing-and-preventing-defects-in-force-com-development/) with more info.

Give me a shout if you'd like some help getting your team going on code reviews.

Great post! Here's the list I like to use:

General

• use config instead of code whenever possible
• DRY - don’t repeat yourself; use VF components, JS & Apex utilities and subroutines, etc.
• provide useful and complete documentation - field description / help text, Apex classes & methods, JS, etc.
• use descriptive names for objects, fields, classes, properties, variables, etc.

Config

• General standards above
• make custom objects and fields as restrictive as possible (required, unique, limited size, validation, precision, etc.)
• prevent duplicates using unique or validation rules
• normalize (no duplicate fields; delete unused fields)
• use camel case names with spaces between words (underscores in API names)
• add Apex unit tests to test config where appropriate

Apex

• General standards above
• no SOQL, DML, or @future calls inside loops
• bulkify all trigger and asynchronous code
• handle all potential errors; comment cases where errors should be ignored
• use asynchronous (future, batch, scheduled) when possible
• no hard-coded Ids
• when querying large data sets, use a SOQL “for” loop
• create at most one trigger per object
• use centralized trigger processing (ITrigger pattern)
• use static queries, binding variables or escapeSingleQuotes to prevent SOQL injection attacks
• clearly separate concerns (model / controller / trigger handler / view / tests)
• use custom settings for constants and configurable settings
• avoid text; use custom labels; use final properties
• avoid hard-coded date, time, number, currency formats
• when a group of fields is specified, use a field set
• follow Java coding conventions (for the most part)
• use spaces instead of tabs
• use whitespace to improve readability
• CamelCase classes, ICamelCase interfaces, camelCase methods, properties, and variables, ALL_CAP finals

Unit Testing

• General standards above
• assert proper behaviors
• test conditionals, valid inputs, invalid inputs
• always runAs a specific user
• write each test for multiple records
• don’t rely on existing data
• 100% unit test coverage

Visual Force

• General standards above
• move CSS and Javascript to static resources
• include Javascript at the bottom of the page
• use transient properties, read-only pages, and caching when possible

In addition to Salesforce's best practices and standards, there are lots of general software engineering practices you should be aware of. In my experience, some of the most important are:

• Design for testability
• Address each potential error
• DRY principal (don't repeat yourself)