Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
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?
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.
