To inaugurate the blog, I’ll start with something prosaic but one where I saved myself a lot of grief over time as I built up large APEX systems. Naming conventions are of course a matter of personal preference. I’ve seen a lot of posts asking for help on the SFDC Apex Forum and many times the poster’s naming conventions get in the way of those trying to assist. Professional programmers will already know all this stuff, so this might be more appropriate for Apex newbies and ‘toddlers’.

Class and method names

• Follow the SFDC conventions. Your code is a mix of SFDC classes and methods so follow the idiom. Class names are initialcaps.
• Method names are initial lowercase. Don’t use underscores. If the method returns a Boolean, make the method name an assertion statement

public class Foo{
  public Boolean isClosed() {
   // some condition that returns true if something is true, else false
  }
}

Consistency in abbreviations

I use a consistent shorthand for my APEX variables (and by extension Visualforce var= attributes).

• Variables that reference Accounts start with ‘a’, Opportunities with ‘o’, Contracts with ‘c’, Quotes with ‘q’, QuoteItems with ‘qi’ and so on.
• Where there is a first letter conflict, I stick to something clear and easily remembered such as ‘cs’ for Case or ‘attach’ for Attachments
• Custom Objects would use a shorthand made up the first letters of each word (or maybe syllable) such as ‘pcr’ for Product_Config_Rule__c

Consistency in references to IDs

• IDs are your friend as they can be used to reference maps, query for SObjects, and are globally unique.  Use your variable names to ‘type’ your Ids
• Thus, aId is an Account Id, qiId is a quote Item Id

Account a;  // the account being worked on
Account aOld; // the prior version of the Account from Trigger.old
ID aId;  // an account Id

Consistency in collection variable names

• You are constantly coding in the bulk idiom or handling result lists from queries. Because SFDC provides different instance methods for lists, sets, and maps and because each collection type serves a different purpose, it greatly improves code readability when the variable name makes it clear whether it is a list, set or map.  I always append my collection variable names with either ‘List’, ‘Set’, or ‘Map’. It also helps you code as you operate on the collection – as you type the variable name, you remind yourself of how it works (for example, maps aren’t in any sort order).
• Since lists are often created to do DML or are the results of queries, add a common shorthand to the variable name as to purpose. For example ‘ins’ for a insert list, ‘upd’ for an update list, or ‘res’ for a query result list

Good names

List<Account> aInsList;  // a list of Accounts to insert
List<Opportunity] oUpdList;  // a list of Opportunities to update
List<Contract> cReslist = [select id from Contract where name like 'Foo%'];  // query result

Set<ID> aIdSet;  // a set of unique accountIds

Map<ID,Case> csIdToCaseMap; // a map of Case Ids to Case SObjects
Map<ID,List<Quote>> oIdToQuoteListMap;  // Map of Oppo ID to a list of Quotes

// Map of Case Id to Case with related lists fetched from a query
Map<ID,Case> csIdToCaseWRelListMap =
  new Map<ID,Case> ([select id, accountId, caseNumber, closedDate, contactId, subject, type,
		     (select id, commentBody, createdDate, createdById, isPublished
			     from CaseComments order by createdDate),
		     (select id, messageDate, subject
			     from EmailMessages order by MessageDate asc)
		    from Case where id IN :csIdSet]);

Avoid doing this…

List<Account> accts;  // when referenced in the code, is it a list, set or map?
List<Opportunity] updates;  // updates of what sObject?

Set<ID> ids;  // a set of Ids to what sObject?