What is a good set of coding conventions for Salesforce development?

I’ve looked around in the Apex and Visualforce developer guides and around the web and can’t seem to find any coding conventions out there. The Apex Dev guide has a section on Naming Conventions that just says to use java naming conventions (which prompted this discussion).

A good place to start might be the Java Coding Conventions since the languages are so similar, but I’m also looking for details about Salesforce specific uses such as formatting SOQL queries, as well as validation rules and formula fields. Is there a good set out there?

Answer

Great question. I haven’t seen a good full set that’s publicly available.

For clients in my consulting days, I’ve written maybe a dozen or so sets of SFDC coding conventions but sadly can’t share them since they were all technically works for hire. For formatting / naming / capitalization, I always started with the Java conventions – if you follow those, you’re already doing better than 95% of SFDC customers.

Typical document like this was 10-20 pages long and designed to be thoroughly absorbed by new technical team members. The sections these documents usually contained included:

  • how to set up your development environment, and how the general team development workflow works.
  • SFDC custom object conventions (field naming, object naming, every field must have descriptive help text and description, buttons vs custom links, etc)
  • Trigger rules (I’m fond of the rule that “every combination of object / before-after / event has exactly one trigger, and vice versa, and they are called, e.g., OpportunityBeforeUpdate”, as well as the rule that triggers contain no real implementation
    code, only callouts to utility methods.)
  • Design patterns (a few teams I’ve worked with were committed to using a type of DAO or Service pattern, where no object-retrieval SOQL, and/or no direct references to SObject instances, are permitted in code outside of the DAO wrappers.)
  • Current overview of code, including important utility classes. This section can be long if there’s a big code base and is designed to be a guide to which classes a new developer needs to familiarize themselves with immediately. Prevents the problem of having dozens of places in code where dates are being converted/formatted differently, etc.
  • i18n / l10n rules, if applicable
  • team security practices, if applicable
  • overall architecture diagram showing integrations, external portals and sites, security measures if applicable
  • use of third-party libraries in Apex and VF, which most commonly were not much more than apex-lang and JQuery / JQueryUI
  • test code guidelines. Almost every Apex developer I’ve worked with who isn’t from a “real” dev background thinks the only reason tests exist is to hit that 75% magic number. So the section mostly ends up being training about what a good test does, and how to make a unit test actually a unit test. (Which sucks and is why line coverage is such a terrible goal to impose on the community. It could be argued that it’s better than nothing, but that’s about all you can say about it.)
  • rarely got into VR’s and formula fields other than error message convention if they didn’t come from a product manager / BA (passive vs active voice, helpfulness, etc)

Anyway, that’s not really an answer to your question but hopefully at least helps people who need to come up with something like this.

Attribution
Source : Link , Question Author : Ralph Callaway , Answer Author : jkraybill

Leave a Comment