This article is Day 8 and second article of the Object Oriented Abuserscategory in a multi-post series about refactoring Code Smells. Code Smells are characteristics that can negatively impact code; ranging from hindered read-ability, clutter, unscale-ability, even outdated programming practices.

Refactoring examples will be mostly, if not all, from the Imperative/OO perspective as ServiceNow OOTB code is somewhat written imperatively. I will try to be brief and attempt to use language features specific to JavaScript that may differ from those used by classically trained coders.

What are Object Oriented Abusers:

Inaccurate or undeveloped OO principles.

Previous Code Smell articles

Day 8 - Refactoring Temporary Field

A Temporary field is a variable that isn't really needed, or used in a very limited situation:

Note: Temporary fields can have their uses cases.

Examples of Temporary fields

• is used in very specific cases
• instead of being passed to other methods, the method reaches out to set or read its value
• Used to track changing values as it passes through logic
• has no functional need other than being a placeholder

Solution

Extract temporary fields be extracted into their own SI, or replace them by passing them as parameters to methods. In a nutshell, structuring code logically often solves the problem. This is done by extracting the variables unrelated to each other into their own SI, and removing those without a real purpose.

Why Temporary Fields smells

• leads to clutter
• identify incomplete code structures
• can increase debugging complexity
• indicative of a mixture of concerns (not always bad, more like how it's done)

Basic Examples of Temporary Fields

function nameToObject (name) {
   var fullName = name.split(' ');
   var firstName = fullName[0];
   var lastName = lastName[1];

   var name = {
      firstName: firstName,
      lastName: lastName
   };

   return name;
}

function sum (a, b) {
  var total = a + b;
  return total;

}

Example Solution

function nameToObject (name) {
   var fullName = name.split(' ');

   return {
      firstName: fullName[0],
      lastName: fullName[1]
   };

}

function sum (a, b) {
  return a + b;

}

In case of Objects and longer methods, temporary fields can lead to bloating, handling too much responsibility, even confusion and increased interpretation times...

Places where their use can help is when breaking down LISP like call points in functional application programming, or when calling curried methods, etc. Rather than a one liner, the line is broken down into multiple.

Predicate(aPredicateStrategy)(aFailureFunction,aSuccessFunction)(valueToCheck)

oneMethod(twoMethod(threeMethod(value)));

Happy SNowing...