Hardcoding: The less the Better
Imagine this scenario: you’re tasked with building a tool that generates a form. The form is simple, needing only simple, static information. Building the tool is relatively simple, as the requirements are simple and straightforward.
You build the tool; the form is created with no problems. People love it, but with that comes new requirements. Now one of those fields needs to be changed on the form. In order to meet this new requirement, you need to rewrite how the fields work in your tool.
Soon, you realize that with every change to the fields on this form, you have to go back into the tool you made and make the change, since every field is written statically to build the form. This is called hardcoding, and it can lead to very inflexible design not just within programming, but with entire business practices.
When starting a project, it is extremely important to consider how a tool or feature should scale to meet future needs. In the context of Salesforce, one extremely useful tool in reducing hardcoding and increasing administrative visibility comes in the form of custom settings. Custom settings can be a list or hierarchy of whatever values you need. They sort of act like Salesforce objects but are meant to be used in scenarios where there’s static data that may be changed in the future.
Revisiting the form tool scenario, say you start the task with flexibility in mind. Instead of just designing the tool to output three static fields, you could instead map it to a custom settings list. This, in turn, can be configured with the fields you need. This is slightly more complex initially, but from now on the only thing that would need to be changed to add, modify, or remove fields is a simple change on the list itself. Suddenly, you’ve built a flexible tool that can respond to changes in requirements quickly.