Eigen X: Coding Standards and Style Guides

A guide for preferred coding standards and styles at Eigen X.

Contents

1. Agile Developer Mindset
2. Requirements
3. Deployment Guidelines
4. Versioning and Source Control Guidelines
5. Style Guide
6. IDE's and Code Editors
7. Testing Guidelines
8. Definition of Done
9. Contributing

Agile

Agile development is not a process, it is a mindset. It's important to note that developers should use their discretion when implementing this guide based on the individual project. For small projects it is prudent to avoid unnecessary overhead, for large projects this repo may need to be forked and adapted to that project as a deliverable.

Individuals and interactions over processes and tools

Favor collaboration and code reviews on Pull Requests over mandating ide's and excessive tooling.

Working software over comprehensive documentation

Favor meeting requirements over excessive

Customer collaboration over contract negotiation

Our goal is to provide the most value within the scope of our projects. We need to be in constant contact with our customers to focus on what is important to them.

Responding to change over following a plan

Tech changes quickly, we should use tech that is appropriate for the project at hand. Favor good tech over old habits.

• Quotes from the Agile Manifesto*

Requirements

Should be a simple yet clear sentence describing who needs what and the benefit is.

i.e. As a I want to [do something], so that I can [realize a reward].

Related:

• Given When Then

Versioning

In all projects there needs to be a reliable method of source/version control. git is the preferred tool.

General Branching Strategy

Branches:

• production: This is the live or production version of the code. The single source of truth for the most up-to-date code. (aka release or master)
• staging: This is the staging version of the code. In Salesforce, it will be deployed to a full or partial sandbox . Testing of new features should be done here prior to a release to production branch. (aka dev)
• dev: This branch should be where development takes place. In Salesforce, it will it will be deployed to a full or partial sandbox so that admins can make changes as well and those changes can be captured in metadata diffs. Branch can be for individual developers or issues/bugs/features. Sometimes if the feature is big there will have to be subbranches merging into this. Naming isn't as important as long as the pull request to staging includes the appropriate ticket number.

Actions:

• release: When code in the dev/staging branch is accepted, a version number should be assigned and the code should be merged to master/release
• pull request: In most cases there should be one pull request for a coinciding bug resolution, feature add, or requirement fulfillment. The pull request should reference the appropriate issue and should include the ticket number in the name of the Pull Request.

Salesforce Specific Source Control

Salesforce often uses Production as the source of truth, which can be problematic. In which case see the Source Code Management section of Software Development in Salesforce.

Source Control Tools

Source Code Management is typically required for larger heavily customized implementations of Salesforce. Its benefits are as follows. Maintains historical record of changes for code review, rollback of changes and management of packages to be released. Facilitates means for continuous integration across packages and sandboxes. Facilitates release management by using Metadata Packages.
Salesforce customizations can be accessed as text or XML through a number of interfaces. The most common are the Metadata API and the SFDX commandline tool which uses the Metadata API.

One of the following should be used:

• Git
• Subversion
• VSTS
• TFS

Deployment

In general, it is good practice to deploy from your master/release branch to your production server. Ideally, each release should contain a list of actions needed to deploy.

Salesforce Specific

Salesforce uses change sets to move code between environments rather then deploying from source. In this case see the Deployment section of Software Development in Salesforce.

Style

Style and coding standards will vary based on language/library conventions.

1. Apex
   • Style Guide: PMD Apex Rule Sets. If applicable, Java conventions should be followed where there is no guidance specific to Apex.
   • Dev Tools:
     • PMD can be used with apex.
2. CSS/Sass
   • Style Guide: Airbnb CSS / Sass Styleguide
   • Dev Tools:
     • Use sass-lint with the airbnb config
3. HTML
   • You should be writing Valid HTML according to the living standard
   • Dev Tools:
     • W3 HTML Validation you can also use a command-line version of this
     • Accessibility Testing
4. Java
   • Style Guide: Google Java Style Guide
   • Dev Tools:
     • PMD
5. Javascript
   • Style Guide: AirBnB Javascript Style Guide
   • Dev Tools:
     • ES Lint
6. Python
   • Style Guide: PEP 8
   • Dev Tools:
     • Pylint
7. Salesforce Lightning
   • General Guidelines:
     • Thinking in Lightning
8. Shell Scripting
   • Style Guide: Google Shell Style Guide
9. VisualForce
   • Style Guide: PMD Apex Rule Sets. If applicable, Javascript/HTML/CSS conventions should be followed where there is no guidance specific to VisualForce.
   • Dev Tools:
     • PMD can be used with VisualForce.

IDE

Developers should use tools they are comfortable with. No standard IDE will be mandated on a project because it is a distraction from productivity. Related: What Editor Do you Use?

Suggested Editors/IDEs

Some of the editors our devs use include:

• Atom
• Eclipse
• Intellij
• Sublime
• Vim
• VS Code

Testing

Testing Strategies should be determined on a per project basis.

General Guidelines:

• A Realistic Approach to Software Testing on the Software Platform
• Commonly Made Mistakes When Testing Software on the Salesforce Platform
• Test Pyramid
• Given When Then

Definition of Done

Definitions of done should be determined on a per project basis.

A 'definition of done' is consistent requirements cross all user stories. Example: Accessibility Testing

Contributing

There are two main branches:

1. master - a release branch that should be considered active and in use.
2. proposal - a staging branch for all proposed changes.

If you have would like to contribute or have a suggestion for this style guide, please submit them by making a pull request into the proposal branch.