Apex Coding

Naming Conventions:

Data Types

• Capitalize the first letter (e.g. String)

Classes and Triggers

• Capitalize the first letter (e.g. AccountTrigger or AccountSearchController)
• Triggers should be post-fixed with the word Trigger
• Controllers should be post-fixed with the word Controller
• Other class names should be descriptive (e.g. EmailService or TaskManager)

Methods and Variables

• Use camel casing (e.g. getAccounts)
• Use method names that are descriptive, in this format: verbNoun (e.g. getAccounts or validateInput)
• Use variable names that are descriptive
  • For maps try to use keyValuesMap or valuesByKey (e.g. accountContactsMap or contactsByAccountId)
  • For booleans try to use verbAdjective (e.g. isDuplicate or hasException)

Unit Tests

• When creating a test class for MyClass or SomeTrigger append Test to the end of the class name (e.g. MyClassTest)
• Use a sentence to name your unit test methods, in this format: methodUnderTest_to_doWhat_on_condition (e.g. getAccounts_to_returnNothing_on_blankFilter or sendEmail_to_throwException_on_nullRecipient)
  • methodUnderTest is the method being tested. If testing a trigger this would be the event firing the trigger (e.g. insertAccount)
  • to_doWhat is what the test is asserting (e.g. to_insertCase means the test is asserting that a Case should be created)

Formatting

• Add comments to classes, public methods, code blocks, and anything that may not be easy to understand by another developer
• Write method/class headers using the JavaDoc format like so:

/**                                                             
*  Queries for and returns Accounts by Id                      
*  @param accountIds List of Account Ids                       
*/                                                             
public static Account[] getAccountsById(Id[] accountIds) { ... }

• Each line should not exceed 120 characters. Continue your code on a new indented line if it's longer than 120 characters
• Remove unused variables, debug statements, and other junk

Structure:

• Break up large code blocks into smaller methods
• Trigger logic should be placed in a corresponding handler class (e.g. AccountTrigger calls AccountTriggerHandler)
• Anything with potential for reuse should be abstracted away in a separate method or class
  • Avoid copy/pasting code at all costs

Unit Testing:

• Each class and trigger must have a corresponding test class
• Integrations and end-to-end processes must have their own test classes
• Each unit test must have at least one assertion
• Try to cover as many test cases as possible (do not just test the happy path)
• Do not use seeAllData=true
• Use Test.startTest() to reset the governors for properly isolating the unit-under-test
• Use Test.stopTest() before assertions and in other circumstances as needed