Naming of Classes and Triggers

[brianmfear]

I'd just avoiding recommending Captain Obvious (CO) names, particularly Pages, Components, and Triggers.

You're in the triggers folder, looking at a file called AccountBeforeTrigger.trigger. This is clearly a trigger, so why did we call it a trigger? Just in case Salesforce gets confused? AccountBefore is a perfectly acceptable name.

Now, you're in the pages folder, looking at ProductSelection_VF.page. We know it's a Visualforce page, otherwise it wouldn't be in this folder. The exception to this rule is that Templates should be named as such: SiteChromeTemplate, or names that clearly define what the thing is: ProductSelectionWizard.

Finally, over in the components folder, why do we: AccountAddressLookupComponent.component? It's clearly a component, but we labelled it as such, again just in case it wasn't obvious. Even in normal Visualforce code, it gets its own name prefix, so there's no way we could confuse that component with a standard Visualforce element.

Next, I'd add suggestions about things you should name consistently:

MyPage has a controller named MyPageController, or, if a non-shared extension, MyPageExtension or MyPageExt (consistently).

Shared extensions (those that span multiple pages) should describe the feature, such as AddressLookupExtension or AddressLookupExt (consistently).

MyComponent has a controller named MyComponentController.

MyTrigger has a "helper class" named MyTriggerMethods or MyTriggerHandler (either sounds okay to me, but consistently).

Webservices classes should have a name that suggests this: GetFilesService or GetFilesWS (again, consistency).

REST Classes should similarly be named with consistency: GetFilesREST.

Utility classes should be named as such: AddressLookupUtil or AddressLookupUtility (either, but consistently).

Wrapper classes should end with the word Wrapper: AccountSearchWrapper.

Mock classes should end with the word Mock: HttpCustomServiceMock.

Exceptions should end with the word Exception: MyCustomException. (The platform actually enforces this, but it's good to know).

Webservices clients that call other services should ideally be called Client: MyCalloutClient.

All other classes that don't fit into any other category should be named as descriptively as possible, but without the word class or any prior word that suggests a particular use. For example: NameValuePair, VechicleIdentificationNumber, TshirtOrderData, etc.

Of course, I'm open to other suggestions, but a basic list of things you should do would help.

[ckoppelman]

I think there's a bit too much heavy-handed-ness here for the purposes of this styleguide. I'll try to either expound on the reasoning behind the Trigger suffix or drop it from the guide.

[brianmfear]

Fair enough. I've personally used this style for longer than I remember, because it helps keeps things organized. In other languages, we have folders, packages, header files, etc that keep things organized. I've found it to be a useful tool, especially as you start wandering into the hundreds-of-classes territory. Java itself has similar guidelines on its classes, if I recall, which are mostly codified in the core libraries. I wouldn't worry too much about naming the way I suggest, but names that are simply redundant bother me. AccountImportWizardControllerClass is certainly descriptive, but AccountImportWizardController gets the point across just as well, without telling me its a class. We (should) already know that AccountImportWizard is a page, and the controller for that page is AccountImportWizardController, and the test class is AccountImportWizardControllerTest.

I don't think it should be a hard and fast rule, but having a strong suggestion about the file's name being descriptive should be in there. There's times you have to break the rules anyway, because you can only have so many characters in a name.

[Szandor72]

Agreed on the Trigger Issue. I will not use trigger any more.

Kudos for the bits on AccountImportWizardControllerClass.

Due to sorting when working with Brainegine or the Developer Console or with MetaData Folders, I use following rules for naming:

(prefix)ClassName(Suffix)

e.g. myPage (VF Page) myPageCtrl myPageCtrlTest

Ctrl and Test are always listed together, which keeps things at hand.

In our Org we got utility classes for most objects that get called in triggers.

opportunityMethods opportunityMethodsTest

My WS or REST classes are similarly suffixed and so are public sites e.g. restKeyAccountAPI restKeyAccountAPITest wsAccountNews wsAccountNewsTest siteAccountNews (VF Page) siteAccountNewsCtrl siteAccountNewsCtrlTest

Talking about Triggers, I would make following things mandatory:

• 1 Trigger per Object only, all events
• Triggers are not allowed to contain any code except triggermethodcalls or methodcalls to utility classes

trigger caseTrigger on Case (before insert, 
                            before update,
                            before delete,
                            after insert,
                            after update,
                            after delete,
                            after undelete){
    if (trigger.isAfter)
        {
            if (trigger.isInsert){
                caseMethods.processCasesAfterInsert(trigger.new);
            }
            if (trigger.isUpdate){   
                caseMethods.processCasesAfterUpdate(trigger.newMap, trigger.oldMap);
            }   
        }
}

Utility methods are common best practice as it keeps trigger tidy and enables better tests.

As for one one trigger per Object covering all events, I decided this and all other rules by asking myself how I would explain my org to the next developer and how to facilitate her digging through the code on her own.