​Throughout the years NimbleUser has written a number of in-house authoritative guides and documents on the Apex programming language. While a good start, our previous guidelines were too complicated and opinionated on the types of things that were unenforceable / didn’t matter in the grand scheme of building good software.

We were also increasingly concerned regarding the process by which documents could be modified, amended as the group ratifies changes to the standards. As software developers, the “code review and pull request” style process works out far more effectively than a classical content management system approval chain process. So, building a guide in the Markdown formatting language affords us the pull request code approach, while maintaining something written in a standard, web-publishable format.

​Don’t We Have Enough Standards Already?

Salesforce has no straightforward guide for how Apex code should be written. They have a lot of examples, and best practices but don’t actually provide a voice of authority on the subject in terms of style. Additionally, extensive research was done by the NimbleUser team into standards followed by other Salesforce development groups and nothing major was found which was authoritative, consistent without being too opinionated.

In keeping with the tradition of “standing on the shoulders of giants”, our Standards Guild recently agreed to adopt and adapt the open source Google Java Style Guide to the Apex programming language. Google’s work provides “hard-and-fast rules that we follow universally, and avoids giving advice that isn’t clearly enforceable (whether by human or tool)”. This new guide is our single point of authority on Apex related standards, internally.

Our initial port has been completed and is available for public consumption in a nice, human readable webpage.  We also created simple URL (styleguide.nimbleuser.com) to access.
Like other programming style guides, the issues covered span not only aesthetic issues of formatting, but other types of conventions or coding standards as well. Our guide focuses primarily on the hard-and-fast rules that we follow universally, and avoids giving advice that isn’t clearly enforceable (whether by human or tool).

Open Source Initiative

To further our contributions to the Salesforce development community overall, the ultimate goal and intent of this document was to have it published on the web, publicly available, allowing the overall Salesforce development community to contribute by suggesting additions and modifications to the document as they see fit.

Anyone with an interest in software standards and a GitHub account can clone the repository and submit a pull request for consideration into the main branch.

Let’s Work Together On This

Thanks for taking the time to read this and here’s to a future with collaborative development standards! Our goal of publishing this is to further the quality of all Apex coding – let us know what you think.