Skip to main content
added 59 characters in body
Source Link
Peter Knolle
  • 29.2k
  • 12
  • 104
  • 164
  1. The first line has the assignment to the variable and the end line has the closing bracket.
  2. Use Uppercase first letter for keywords (seems to work well with syntax highlighter in IDE and, isn't a pain to type, and the Force.com IDE's schema browser generates it that way).
  3. Group like fields on the same line (e.g., from the same parent), breaking for new groups of fields or if it gets too long to fit in a reasonable IDE window (100 characters?).
  1. The first line has the assignment to the variable and the end line has the closing bracket.
  2. Use Uppercase first letter for keywords (seems to work well with syntax highlighter in IDE and isn't a pain to type).
  3. Group like fields on the same line (e.g., from the same parent), breaking for new groups of fields or if it gets too long to fit in a reasonable IDE window (100 characters?).
  1. The first line has the assignment to the variable and the end line has the closing bracket.
  2. Use Uppercase first letter for keywords (seems to work well with syntax highlighter in IDE, isn't a pain to type, and the Force.com IDE's schema browser generates it that way).
  3. Group like fields on the same line (e.g., from the same parent), breaking for new groups of fields or if it gets too long to fit in a reasonable IDE window (100 characters?).
Source Link
Peter Knolle
  • 29.2k
  • 12
  • 104
  • 164

@jkraybill gave an excellent overall answer.

For SOQL, I like to keep it as readable as possible so that I can see its function in a quick scan. I might move the query into its own self describing named function, too, if that helps.

  1. The first line has the assignment to the variable and the end line has the closing bracket.
  2. Use Uppercase first letter for keywords (seems to work well with syntax highlighter in IDE and isn't a pain to type).
  3. Group like fields on the same line (e.g., from the same parent), breaking for new groups of fields or if it gets too long to fit in a reasonable IDE window (100 characters?).

3.1. Primary fields of an object first.

3.2. Parent fields second.

3.3. Related lists last. 4. Four spaces for indentation. 5. Indent for readability.


List<Account> accts = [
    Select   
        Id, Name, AccountNumber, Description,
        BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry,
        ShippingStreet, ShippingCity, ShippingState, ShippingPostalCode, ShippingCountry,
        (Select 
             Id, Name, CloseDate, StageName, Description,
             Account.Name, Account.AccountNumber
         From Opportunities
         Where Name = 'ABC'),
        (Select
             Id, FirstName, LastName
         From Contacts
         Where FirstName = 'Peter'
             And LastName = 'Knolle'
             And Email = '[email protected]')
    From Account
    Where Id In :setOfIds
        And Name Like 'Heroku%'
        And AccountNumber
];

All that being said, for a simple, compact query I will break that rule and write a one-liner.

   List<Account> accts = [Select Name From Account Where Id In :ids];

Or a simple three liner.

List<Account> accts = [
    Select Id, Name, AccountNumber
    From Account
    Where Id In :setOfIds
];
  • I usually stick to the rule of keeping the formatting consistent within a single file, so if I'm editing some legacy code I may not apply new rules, but rather stick to whatever rules have been adhered to within that file.

  • Readability is of utmost importance. I don't care as much about adhering 100% to the indenting rules when code reviewing, as long as the query is 100% readable.

  • I used to have more line break and indenting in SOQL formatting such as near the From clause, but I felt that the queries weren't gaining any readability from it.

You could probably search for SQL formatting for some other suggestions that could be translated over to SOQL.