4

Currently we have multiple applications in our client org. It's hard to identify which components like Apex Classes, Visualforce Pages, etc belong to each application unless we look into each component. Are there any best practices to follow to separate components based on each application like naming conventions?

For applications installed from app exchange is easy to identify by name space prefix. But are there any best practices to separate components by custom application?

Improve this question
2
  • 1
    I normally prefix classnames with my own namespace, such as stackexhg_PullNewQuestions, to differentiate from other components.
    – Salesforcesmarty
    Mar 29, 2017 at 23:32
  • 2
    The description field is incredibly useful for 'linking' to a user story (or similar tracking system) to demonstrate why it was created and what it was intended to be used for. Naming conventions 'per application' can become sticky. What happens when you've got two 'applications' that have an identical use case for a particular field - but the existing field on an object belongs to the other application? Do you use it? Plan your implementation across project boundaries as best as you can so you don't end up with a bunch of technical debt and duplicated stuff in your implementations.
    – Mark Pond
    Mar 29, 2017 at 23:56

1 Answer 1

Reset to default
6

Salesforce has an idea for organizing code. It's eight years in the making, but it is under PM review, so they're at least considering it. Also, once Salesforce DX comes out, we'll have "artifacts", which lets us put code into folders for organizational purposes, but those only apply in your repository, not on the server itself.

For now, what many developers do is to create a standard name scheme in order to keep things sane. It doesn't matter what you do as long as you're consistent. The main point is consistency. Also, you need to be flexible. It's likely that you'll have code that exists in utility classes to reduce code size.

Some examples follow. When I create a class, I create a unit test class that is the same name followed by Test (e.g. AccountTriggerHandler would have a unit test class of AccountTriggerHandlerTest). When I create a page or component, the controller class will share a similar name (e.g. AccountTeamView page would have a AccountTeamViewController class and a AccountTeamViewControllerTest unit test class). When I create a trigger, I create a trigger named after the object, a trigger handler class, and a unit test for both.

The more consistent you are with your naming, the better off you'll be. In addition, it's strongly recommended that you have documentation, such as a wiki, or even use an automation documentation system like ApexDoc. The more documentation you have, the better off you'll be. Eventually, we will have better organization abilities, but until then, it's up to us to stay disciplined.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .