I've seen Apex code examples write out Schema.SObjectField-typed constants in both of these formats:

  • Schema.Account.AccountNumber
  • Schema.Account.SObjectType.Fields.AccountNumber

Why two different approaches?

Are there any features I'd lose by choosing the concise one instead of the long one?

I can see how the latter would be useful if stopped at the 4th piece, Fields, and were then iterating over its contents. But I've seen examples where it's literally written out as a 5-part literal, and I'm not sure exactly why.

Note: Not quite the same question at Account.sObjectType.getDescribe() vs Schema.sObjectType.Account in my opinion.

  • The other two "feel" noticeably different from each other due to arriving at the same Schema.DescribeSObjectResult via very different "first class listed" paths, whereas I'm interested in two that "feel" noticeably redundant, yet both appear in the wild (e.g. fflib tutorials).
  • Also, while I'm glad to be pointed to that thread and see that there's an answer of "nope, no noticeable difference" for that particular scenario that deals with Schema.DescribeSObjectResults, this is about Schema.SObjectField (and, again, a different set of syntaxes from that question).

Just to be safe, I'd rather leave this question open until someone chimes in with an opinion about this particular case and whether people with the "5-part literal" approach are just being needlessly verbose, or whether there's a reason to use the "5-part literal" over the "3-part literal."

Thanks so much!

  • 4
    Possible duplicate of Account.sObjectType.getDescribe() vs Schema.sObjectType.Account – identigral Sep 24 '19 at 15:42
  • I mean, not really ... that question is about the reasons to choose between two different approaches to returning a Schema.DescribeSObjectResult. I'm asking about the reasons to choose between two different approaches to returning a Schema.SObjectField -- and whose syntax don't even start with different outermost classes, at that. Thanks for bringing the other post to my attention, though! – k.. Sep 24 '19 at 17:07
  • 4
    It amounts to the same thing - Schema.Account is a shortcut. It's Apex equivalent of a syntactic sugar. – identigral Sep 24 '19 at 17:15
  • Thanks @identigral -- if you'd like to make that an answer, feel free so I can accept it (presuming no one else comes swooping in to argue with you). :-) I will use the shortcut whenever I am using a straight-up single-field literal. *Takes snippers to copy-pasted code from wordy tutorials* – k.. Sep 24 '19 at 17:19
  • 3
    for what it's worth, you can even leave Schema. away, e.g. Product2.language__c.getDescribe(FieldDescribeOptions.FULL_DESCRIBE) works fine – Christian Szandor Knapp Sep 24 '19 at 17:21

There's no real difference; the latter is just more verbose. Either way, you get a hard reference to a SObjectField. That hard reference is then reflected in your SymbolTable, and a dependency between your code and the field is persisted, blocking any deletion or renaming of that field.

Speaking of verbose, note you can drop the leading Schema. for either of the above approaches, unless you have a local variable or class named Account.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.