Deleting Classes

Question

When you delete an Apex Class or Trigger is there a difference between doing it through an IDE vs a destructiveChanges.xml? Does using destructiveChanges.xml purge the Class completely? What are the best practices for removing Classes/Triggers? Are there any unforeseen issue that could occur using one approach over the other?

Answer 1

When you delete an Apex Class or Trigger is there a difference between doing it through an IDE vs a destructiveChanges.xml?

Typically, no. They both follow the same rules of engagement. Many IDEs actually do use destructiveChanges.xml under the hood anyways, although some instead use the Tooling API or Salesforce DX (when available). Those IDEs still have to fall back to the Metadata API when deploying to Production anyways.

Does using destructiveChanges.xml purge the Class completely?

Yes, unless you're an ISV developing a managed package. In that case, they're soft-deleted first unless you use purgeOnDelete=true in the deployment settings. Note that this only applies to components that are already in the package and uploaded in a previous version.

What are the best practices for removing Classes/Triggers?

Use a CVS (Code Versioning System) to store your code and other metadata. Deleting a file is a serious affair, so if you accidentally do something bad, you'll have a hard time of fixing it without a backup. Note that production prohibits deletes that would cause compilation errors or unit test failures, so always make sure your unit tests are testing your code properly, and make sure you remove the unit tests for triggers or classes being deleted.

Are there any unforeseen issue that could occur using one approach over the other?

No. Both are particularly risky in a Sandbox/Developer Org, because of the potential to cause compilation errors, and particularly safe in Production Orgs because of the restrictions that generally prevent putting your system in an unusable state.