function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Any ideas on how to make the tangle of classes and triggers organized?

Until Salesforce gives us some way to organizing files my org is stuck with 200+ classes, triggers, etc lumped onto one page view.  In the past we've come up with naming schemes to try and keep files together, but that stops really working after 70 or so files IMO.  Has anyone else tried to implement some type of naming convention or organization to the mess of classes and triggers?


I'm getting more pressure to do more Apex-only development for small projects (ROI I suppose), but it's hard when I know I can just create a .NET sln and then be able to FIND (not to mention debug) the classes 6 months down the road. 




I assume with this much programming that you're using Eclipse.   Remember that you can have multiple Natures ( Projects) set up for the same account.  So, when I've had a lot of work for one client that is all going into one sandbox, and things were getting confusing, I'd just open a new Project into the same account and only put into the new Project the metadata (classes, VF pages, etc.) that I need for that bit of functionality.  Sure, it's not as nice as perhaps supporting project subfolders under the main project, but it works.


Establishing a naming convention for your stuff is also a really good idea.  I try to use (Trigger|Controller|Test|Util)_ObjectName_Behavior.   Sometimes shortened to T_, C_, Test_, U_ etc.


Also, if you have a lot of trigger complexity, having a dispatch trigger for each object which then calls the trigger behaviors you've set up in various classes instead of glomming it all into one huge Trigger class, is also a good idea.


Best, Steve.


Hey, thanks for the reply.  We're using Eclipse for sure, and the default breakout of the src filder is decent for overall organization.  We'ce implemented some SOP in regards to triggers and classes, where triggers have little, if any real logic in them, and instead call classes.  The classes are pretty lightweight and if they need to do heavy work, they use Helper Classes that are specifc to that table and have a matching test class.  A typical example of trigger stup:


OpportunityProcessSold.trg (note the table first)



can call


which has a related

OpportunityHelperTest.cls that just tests all of the helper methods


Also, there's an OpportunityProcessTest.cls that handles just the trigger/class testing.



What is a bummer here is that we then create a lot of files, and it goes from project-centric to table/use centric which can make some things hard to find if you can't recall the specifics of what something is doing.


Anyway, I was just seeing if there are others out there in the same boat.  I've posted this in the Ideas KB before, so I'll dig that up and see if it's more than the 6 votes I assume are there.