Magic Strings – They hurt

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.

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.

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!