I'll throw in my bits on variable naming conventions (no doubt controversial to some) but they work for me
Boolean variables
Try real hard to name these so when read aloud, indicate that when used in an if statement or in a VF-referenced boolean getter, the name reads as the 'true' value. (SFDC uses this approach for SObject field names such as Opportunity.isWon so consistency was my guide here)
Example
Boolean hasExceededCapacity;
if (hasExceededCapacity) ...
public Boolean isDisabledFromEdit {get; private set;}
List, Sets, and Maps
Because the methods are different on these collections and they also serve different purposes (e.g. Lists can be indexed, used for DML, ...; Sets are good for uniqueness; Maps are directly indexable by key and crucial to bulkification), I like to suffix my collection variables with either List, Set, or Map.
If a List, the List is named with some prefix indicating what is being collected followed by the purpose of the list
List<Account> aUpdList; // List to use in DML statement to update Accounts
If a Set, the Set is named with some prefix indicating what is being collected followed the purpose of the set
Set<ID> oIdSearchSet; // Set of OpportunityIds used in a SOQL where clause
If a Map, the Map is always named as keyToWhatMap as in..
Map<ID,Account> aIdToAccountMap; // Map of account Ids to Accounts
Map<ID,List<Account>> aIdToAccountListMap; // Map of account Ids to List of Accounts
The advantage to the above is that when you have a method/class with lists, sets, and maps, it is easy to see (particularly months later) what each variable does and what its inherent 'limitations/features' are as you debug or extend.
I eschew the approach so commonly seen in SFSE code posts:
List<Account> acct; // not even a plural variable name!
Map<ID,Contact> contacts; // variable name implies a list but is declared as a map!
this
Lastly, although not strictly required, whenever I reference a class member variable in a method, I try real hard to prefix by this.
public class Foo {
Integer aUpdCounter;
public bar() {
this.aUpdCounter++; // use of this.
}
}
The reason I do this is when the class spans more than one screen's worth of my IDE, I like to be reminded when reviewing the code which variables are local to the method and which are class instance variables.
