I am following an apex class naming convention in a couple of projects for a while and its turning up well and big timesaver for me, so thought of sharing with you all.
Why a special naming convention ?
You must be thinking, “why a special naming convention ?“ This is required because apex classes doesn’t support nested namespaces or packages(java) to organize code in a clean way. So mostly the “classes” area for an org with reasonable code ends up in a mess. Its hard to tell which class is of what use most of the times. A good example with few classes would be
ContactDuplicateCheck < Used in contact dedupe trigger
OpportunityAmountValidator < Used to validate opportunity amount in a trigger on opporunity
OppLoadController < Visualforce controller
AccountLoader < Visualforce extension used to load accounts
ContactMergeExtension < Contact merge based on custom logic, an extension class for a VF page.
ContactService < WebService based on Apex
BulkRecordCleaner < Batch job that cleans the records.
NightlyAccountSync < Nightly scheduled job that syncs the system accounts.
It would be hard to tell the use/purpose of above classes, without the desc I added. But this situation is more panic, when many developers are working on the same code base.
Better Naming convention !
Approach 1 : Prefixing class names
Apex class names can be prefixed based on the functionality, feature etc
“{prefix}_classname.cls”
Approach 2 : Suffixing class names
UPDATE : 16/Nov/2011 : Based on discussion in post comments with @jpseabury & @RalphCallaway, another approach was highlighted to do the suffixing in similar way. The plus of doing this is “Classes would be correctly sortable in “Apex Classes” section in setup area.” For more details on this, please check the respective comments in this post.
“classname_{suffix}.cls”
Suggested prefixes/suffixes based on scenario
page : For all controller and extension classes connected to visualforce pages. Ex. names would be page_OppLoadController, page_AccountLoader.
trgr : Any class used by triggers. Example class names would trgr_AccountTriggerHandler, trgr_ContactDuplicateCheck, trgr_OpportunityAmountValidator
hlpr : For all the classes, that are having reusable code for helper or utility functions. For ex. any code that is common and reused between triggers and page controllers.
btch : Classes for batch jobs.
schd : Classes for scheduled jobs.
glbl : All global classes.
ws : All classes declaring web services in them.
test : For all test classes.
You can easily imagine, how easy would be the life on a reasonably big project with many apex classes.
This is how the above class list will look after prefixing.
trgr_ContactDuplicateCheck
trgr_OpportunityAmountValidator
page_OppLoadController
page_AccountLoader
page_ContactMergeExtension
ws_ContactService
btch_BulkRecordCleaner
schd_NightlyAccountSync
Isn’t it cleaner and self explanatory.
Your thoughts and views ?
Looking forward to those …
Launched in 2015, used by 9000+ worldwide users. It's a suite of tools for Salesforce consultants, architects, admins & developers.
Comments (6)
Anonymoussays:
November 12, 2011 at 1:43 pmWe use a variation of this for two Orgs that I'm currently involved in. With this prefix naming convention, it can be difficult to find code easily using the Alphabet sorting aids at the top of the UI.For example, if I am in the Apex Classes Administrator UI view (Setup > Develop > Apex Classes), and I click on the Name column to sort all the classes by name, then click on “T” at the top of the List View, I'll get a list of every Apex Class that is evoked by a Trigger. In our org, that is dozens and dozens of Apex classes. Scrolling through them to find the specific class I'm looking for can be cumbersome. I find myself having to create a lot of custom Apex Class list views, just so I can quickly find the classes I'm working on — and any other classes that may be related to that object (i.e., create a list view labeled “Contact Related Apex Classes”, and in the filtering section use something like “Name contains Contact”).I agree standardization is important and helpful, but it still feels like there should be an easier way to “namespace” our code.
Anonymoussays:
November 12, 2011 at 1:56 pmI 100% agree with your point @JP. With this way of prefixing namespace, working on classes from setup area would be tough call. When I need to work organise classes on a long running project, I use the same approach, create a couple of views. Though, I opted this approach for a couple of reasons. I mostly love to work from Eclipse/Force.com IDE, this might be because of my Java days love with Eclipse. So I find it handy for classes to be named like this. This prefixing also helps me in packaging the stuff sometime, I know what a class is upto when I am adding it to a package. Yes, this prefixing is not picture perfect, their is a scope of improvement. Lets all discuss more on this, until Salesforce comes out with some simple solution to this problem. I feel Apex is no more a basic OO language for CRM customizations and small products, expectations and usage will turn Apex into a full fledged language soon, recent introduction of “heap dump” and coming feature of mapping of apex classes to Java code directly seems to be few steps in that direction.
Anonymoussays:
November 12, 2011 at 8:49 pm@JP Seabury, totally agree using a prefix to specify the purpose over groups things. In general I've used prefixes as a replacement for name spaces. If a bunch of classes are related they all get the same prefix. At some companies I've worked with they'll specify a 6 character prefix for all projects.That said, I do use suffixes in the same manner. This will let you create list views for just batch, or just test, or just controllers, but you still retain the sortability by name
Anonymoussays:
November 14, 2011 at 1:18 amThanks @Ralph for your views !I liked your idea about suffixing the classes in a similar way to tackle the issue of sorting in setup area. I would say adding 6 char prefix is good for CRM customization projects, but if we are developing an App for App Exchange that are mostly released as managed package, so we will get a prefix automatically. Still I liked this idea for CRM customizations, makes sense for a few good reasons, but it should be 6 char suffix for the same problems instead of prefix. I am happy this post is getting good points to sort out the namespace problem with Apex classes. I will update this blog post soon, to add the new points your brought up. – Thanks for the views/suggestions.
Anonymoussays:
November 16, 2011 at 10:17 pmOh, I just reread the post. Page is a better idea. My bad – you can delete my last post. 🙂
Anonymoussays:
November 17, 2011 at 2:16 amThanks Alex !!