Press ESC to close

Self Explanatory naming convention for your Apex Classes

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


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.


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 …

Comments (6)

  • Anonymoussays:

    November 12, 2011 at 1:43 pm

    We 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 pm

    I 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/ 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 am

    Thanks @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.

Leave a Reply

%d bloggers like this: