Avoiding hardcoding in Apex is a critical best practice for keeping our code flexible, maintainable, and adaptable to new changes. Hardcoding values, particularly record types, record IDs, profile IDs, and object field names, can have several drawbacks. This post will explain the best practices to avoid hardcoding in Apex for cleaner Salesforce code.
Drawbacks of Hardcoding in Salesforce Apex
1. Lack of Flexibility
Hardcoded values require frequent code changes when business requirements evolve. This will require complete code testing that can increase timelines for new changes. For example, Changing the hardcoded record ID or picklist value demands code updates and testing for existing and new changes.
2. Environment Dependency
Due to differences in record type IDs or other settings, hardcoded values may work in one Salesforce environment (e.g., sandbox) but not in another (e.g., production). Test classes will also fail during deployment because the hardcoded ID does not exist in the target Org.
3. Code Duplication
If a value is hardcoded in multiple places, updates must be applied in each instance, resulting in redundant effort and an increased risk of errors. This will increase test efforts for new changes as well.
4. Difficult Testing
Hardcoded values limit the ability to create reusable and adaptable unit tests because data may differ between environments. This can increase testing efforts for new and existing changes.
Mitigation Techniques to Avoid Hardcoding
- Use custom metadata types
- Use custom settings
- Custom Labels for User Facing Text
- Environment-Specific URLs using Named Credentials
1. Use custom metadata types
Custom Metadata Types enable configuration values to be managed declaratively and deployed across environments with values. We can change these values anytime in production as well.
The method calculateProductTax calculates tax using a hardcoded tax rate of 0.05. Later, when the tax rate changes, we must change this code. The method calculateTax uses a custom metadata type. We can change the tax rate by changing the value in the FixedTaxRate__c field anytime. This will make our code configurable and maintainable.
2. Using Custom Setting
We can also remove hardcoding using Custom Settings in the code. Custom Settings store configurable data for businesses.
The method calculateTax uses a custom hierarchy setting. We can change the tax rate by changing the value in the FixedTaxRate__c field anytime, making our code configurable and maintainable.
We can use a Custom Setting or Custom Metadata type to store record type, profile ID, or record ID. This will make our code more configurable and maintainable.
3. Custom Labels for User Facing Text
We put the hardcoded text for error messages or alert messages in the code. When the error message or text changes, the code must be changed. To make it configurable, we can store text strings visible to users (e.g., error messages, information, and prompts) in Custom Labels. This makes localization and changes easy without changing code.
// In your Apex class
String errorMessage = Label.CustomLabel_TaxInfo_Missing_Error;
throw new CustomException(errorMessage);
4. Use Named Credentials for Callouts
The developer normally puts a hardcoded URL as an API endpoint when we do integration work. This will require code change when we need to change the endpoint URL.
Rather than hardcoding external API endpoints or credentials, use Named Credentials. These enable you to configure endpoint URLs and authentication data declaratively in Salesforce.
Check out samples to use named credentials in real-time integration projects.
Summary
By avoiding hardcoding and implementing these mitigation strategies, we can ensure that your Salesforce Apex code is more adaptable, maintainable, and scalable. This makes it easier to support and evolve over time in both development and production environments.
References
Why You Should Avoid Hard Coding and Three Alternative Solutions
Related Posts
- Optimizing Salesforce Apex Code
- DML or SOQL Inside Loops
- Limiting data rows for lists
- Stop Describing every time and use Caching of the described object
- Use Filter in SOQL
- Optimize Trigger
- Bulkify Code
- Foreign Key Relationship in SOQL
- Handle Heap Size for Apex Code Optimization
Other Important Posts
- How to Integrate Google reCaptcha v3 into the Salesforce Experience Site
- The Ultimate Checklist for Efficiently Querying Large Data Sets
- Ultimate Guide to Integrate Stripe with Salesforce CRM
- How to Seamlessly Integrate Shopify with Salesforce
- Ultimate Guide to URL Accessibility in LWC
Need Help?
If you need help implementing this feature, connect with me on my LinkedIn profile, Dhanik Lal Sahni.
