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.
Isn’t it cleaner and self explanatory.
Your thoughts and views ?
Looking forward to those …