Hardcoded values: I know that this topic has been discussed many, many times. Hardcoding is something you do not want to have in your code base if you name yourself a good developer. This applies not only to ServiceNow scripting, but to scripting in general.
If we assume that loops and conditional statements are the A and B of scripting, then avoiding hardcoded values must be somewhere around C or D. It must be part of the curriculum of every single programming course, and I know it is. My coding teacher was calling them magic numbers. Yet, I find hardcoded sys_ids and encoded queries here and there.
That is why I decided to write yet another article on the topic and show how I am doing it.
I usually follow two approaches – based on the customer and the established scripting practices, I can decide to use either of them or use them in combination. Both can be found in ServiceNow native production code.
Let’s dive in.
Option One: Use system properties.
If this the first time you hear of system properties, this is nothing more than a ServiceNow table 'sys_properties' where you can define key-value pairs, on which you can then base your business logic. There is a GlideSystem() method gs.getProperty() which accepts the key (name of the property) and returns its value. For more information, check out the GlideSystem API documentation here.
An example of such property (there are thousands of them OOTB) is 'com.snc.incident.copy.enable'.
It is a system property with the help of which admin personas can enable or disable the copy incident feature, as stated in the description.
Naming conventions usually follow the product/scope to which the property relates, but not necessarily. It can be any sequence of characters, also known as a String.
Now let’s see how can we make use of these in our scripting.
Imagine that you have the following business rule, which sets default assignment group for each new incident:
Anyone, different from the business rule creator will not be able to identify who is the default assignee, because this is a… hardcoded sys_id and does not speak at all. In fact, the business rule creator will not able too 😊
To make it readable, we can add comments, but still, a hardcoded sys_id – if a change is needed, it must be done by someone with programming knowledge.
We can solve these problems by moving the sys_id into a system property with a proper naming and edit the business rule to get the property value.
This business rule, along with the newly created system property will work exactly the same way as the first version of the business rule will, but:
- It does not require pro-coders to change the default assignee.
- Has proper naming and shows clearly who is behind the sys_id
- Provides description and guidance on how to quickly change the value
Option Тwo: Use script includes to store constants.
This is another popular approach used by ServiceNow in their own code.
Example of such OOTB script include is IncidentState()/IncidentStateSNC(). This is a place where incident states are defined as constants.
Looking at that example, one can quickly conclude that this business rule:
Is way more readable than this one:
Looking at the first piece of code, even non-technical person can see that we are aiming to set the state to NEW. Looking at the second, even a technical person cannot be sure what’s behind the magic value of '1'. What the heck is '1'?
Apart from the added value of readability, it also adds value to the maintainability. Imagine that, due to some reason, you have 12 business rules that are setting the incident state to New, but following the second approach – with the '1' hardcoded in the business rule. And imagine that, due to some other reason, you need to modify the incident NEW choice database value from '1' to '11'. You need to go through all these business rules and modify the value in the script with the new value – '11'. Which is as much self-descriptive as its predecessor...
In the same situation, if you have used constants instead, the same thing could have been achieved with by adding a single charecter to the code – in the Constants class (script include), where you would replace the value of the constant IncidentStateSNC.NEW to be equal to '11' instead of '1'. And the magic is done. Everything will work without the need of further changes on the business rules.
Hope that will give enough reasons for more and more people to incorporate scripting best practices in their daily scripting challenges and make not only ours, but their own lives easier too!
Happy coding!
Feel free to spread across your network. Thank you!
Martin Ivanov
Developer MVP 2023
Community MVP 2023
