Strategy for removing Hard-Coded State Values

Javier Arroyo · ‎08-10-2018

DISCLAIMER:
I consider ServiceNow OOB coding practices, and that of the community at large unscale-able and not easily maintainable. Credit to ServiceNow that slightly improves it's code with each new release; even if small, it's certainly a step in the right direction.

----------------------------------------------------------------------------------------------------------------------------------------------------
A bewildering practice synonymous with unreadable code is that of hard-coded numbers to set states (or values for drop-down lists). Couple it to business logic spread about Business Rules, Script Includes, UI Actions, Client Scripts, Workflows, Action Scripts, Widgets, etc, it is no surprise simple changes can introduce various side effects and great efforts...

As ServiceNow has began to introduce this new approach of Data Dictionaries (IncidentState, ChangeRequestState) for state management, coders should follow the practice by introducing their own. Quite often, 'when in Rome'... is not a valid response to abide by ineffective coding practices, nor its impact, whether in time, effort, or financial.

While a seemingly insignificant strategy, introducing a data dictionary has a big impact on maintenance and readability.

Steps of the Strategy:
1. Introduce a Script Include (In which-ever pattern of preference (Constructor/Factory, Object Literal, IIF, etc)
2. Define Object Properties to be used instead of hard-coded numbers.
3. Call the properties from code rather than hard-coding integers into code.
( I still lookup what SomeObject.state = -12 means)

There is plenty to address in the piece of code below but... In this article, only the steps above will be addressed.

The code below:

 var someTableRecord = new GlideRecord('some_table');
 someTableRecord.addEncodedQuery('active=true');
 someTableRecord.query();

 someTableRecord.setValue('state', -5);
 someTableRecord.updateMultiple();

Becomes:

 var someTableRecord = new GlideRecord('some_table');
 someTableRecord.addEncodedQuery('active=true');
 someTableRecord.query();

 someTableRecord.setValue('state', Some_Table.State.UNDER_REVIEW);
 someTableRecord.updateMultiple();

The key line is:
someTableRecord.setValue('state', -5);

It has been adjusted to

someTableRecord.setValue('state', some_table.State.UNDER_REVIEW);

With the addition of a "Constant" to hold an informational message, it becomes trivial to identify the intention of the code. This will be a favor to those souls tasked with maintaining our code.

The script include then looks like such:

var Some_Table = {
   State: {
       UNDER_REVIEW: -5,
       APPROVED: -4,
       IN_PROGRESS: 4,
       ...
   }
};

From this point forward, anytime, from anywhere, that setting State for Some_Table is to be done, it should be by using Some_State object. With this method, when options are retired, added, even changed, there is one and only one place that requires updating for the update to be available everywhere: in Script Include Some_Table.