Naming variables. Is naming 'var gr' dangerous or not?

In this article I want to explain:

• What are the best ways to name a variable in ServiceNow
• Why writing a code in functions is really good practice
• What are benefits of using both of above
• Why we shouldn't ignore this

I will provide real life scenarios, so you can understand better.

Interested?

So lets go!

Two ServiceNow developers are working on business rules, each targeting different tables in the same ServiceNow instance.

Both use Glide Record to query data, but focus on different aspects:

• Developer A on the Incident table
• Developer B on the Change Request table.

Developer A's Business Rule on the Incident table:

Developer B's Business Rule on the Change table:

Consider a situation where an incident is spawned from a change request.

Both of these business rules would be activated nearly at the same time or in overlapping contexts.

In a typical setting, where both developers used a non-descriptive variable like 'gr', there would be a risk of data confusion between the two scripts.

How to prevent such scenario?

If instead of naming 'gr' Developer A used more descriptive variable naming like 'incGr' and Developer B used 'chgGr' for their respective GlideRecords it would prevent the overlapping.

This eliminates the possibility of the Glide Record variable from Developer A's script mistakenly referring to the change request data from Developer B's script, or vice versa.

By following such straightforward but effective variable naming conventions, both developers ensure that their scripts operate on the intended tables, reducing the likelihood of problematic data overlaps.

Lets go through one more scenario, but with this one we will see how function scope works.

Both developers decide to add some utilities for their respective tables in Script Includes.

First lets understand function scope:

Output:

Developer A's Script Include:

Developer B's Script Include:

What happens if both Developer's Script Includes will be used in same script ?

JavaScript generally has function-level scope, which means that variables declared within a function are not accessible outside that function.

In the given example of ServiceNow Script Includes, each utility function (getHighPriorityIncidents and getEmergencyChanges) declares its own gr variable within its own function scope.

As long as these functions are not nested or otherwise sharing the same execution context, there shouldn't be a problem with the 'gr' variable being overridden by the other.

Each function has its own distinct scope, so the 'gr' variable in getHighPriorityIncidents is separate from the 'gr' variable in getEmergencyChanges.

If these two functions are called independently, even within the same script, they won't interfere with each other's variables.

Here's where the confusion might have arisen:

If you have asynchronous code execution where these functions are not isolated (like callbacks, Promises, or other advanced JavaScript features that may share scope), then you could potentially have issues with variable overlap.

However, this would generally require a more complex setup than the straightforward, synchronous Glide Record queries shown in example.

In summary, function scope should protect the gr variables in the two Script Includes from affecting each other when used in the same script, as long as the functions are being called in a straightforward, synchronous manner.

So even if two Developers defined 'var gr' in their Script Includes as long as they defined it within function scope it won't cause any problems even when both Script Includes are used in the same Script.

This is because code executes line by line (I am not speaking of asynchronous code execution).

So first function of Developer A will return it's result.

Then function of Developer B will return it's result and even if both use same variable name 'gr' they will not overlap.

1. Even if variable overlap is really rare scenario it can happen, especially in large instances.
2. To prevent variable overlap use both descriptive naming of variables like 'incGr' instead of just 'gr' or even 'activeIncGr' to be more descriptive.
3. To prevent variable overlap you can combine descriptive variable naming with 'dressing' your code in functions. For example you can write your User Criteria like this: