Topic: Why Magic Strings are bad and how to avoid them
Target Group: Admins & Developers
Complexity: Medium
I had a problem I didn’t even know I had until someone pointed it out.
While coding, building flows, creating validation rules, defining objects or alike we like to use “Magic String”.
Before someone told me about it, I didn’t even know that’s an anti-pattern.
Example Magic String
if(company_type == ‘Fabulous Customer’)
//do something
So, what’s the problem?
It’s hard to maintain!
Let’s assume, the company_type is changed to “Amazing Customer”. It’s very, tedious to update all the places “Fabulous Customer” is used.
Furthermore, a simple spelling mistake in one of the many places “Fabulous Customer” is used will break everything.
Solutions:
Use something strongly typed like a Custom Metadata Type or a final String. At least use the “API value” if it’s a picklist instead of the Label.
Example Magic Field:
Field: Account.Next_Step__c of type Text
I’ve built this field many times over, especially for awesome admin’s, it feels like a magic Text field. You can control (and debug) complex business processes.
Often I have a whole orchestrations of logic running on that text Field.
So, what’s the problem?
It’s widely unpredictable!
Since it’s a text field, you never know exactly what will end up in that field. A data migration, another process or just a unknowing user can write all kinds of values in that field.
That’s where the term magic originally came from.
Solution:
Try to avoid these fields if somehow possible. If you still go with it, again use something strongly typed. In this case a Picklist with Restricted Values, optimally globally defined.
And now I’ve to go off and clean the thousand of places where I use magic strings in my implementations.
Disclaimer: I’m no Magic Strin expert, just learned about it recently
PS: Everything above is true for Magic Numbers, they are even worse!