Summary of 11 amazing JavaScript code refactoring best practices

There is an inherent relationship between patterns and refactoring. From a certain perspective, the purpose of design patterns is to provide targets for many refactoring activities.

1. Extracting functions

In JavaScript development, we spend most of our time dealing with functions, so we hope that these functions have good names and the logic contained in the function body is clear. If a function is too long and requires several comments to make it easier to read, then it is necessary to refactor these functions.
If there is a section of code in a function that can be isolated, it is best to put this code into another independent function. This is a very common optimization task, and the benefits of doing so are mainly as follows.

• Avoid very large functions.
• Separate functions facilitate code reuse.
• Independent functions are more easily overridden.
• If an independent function has a good name, it itself serves as a comment.

For example, in a function responsible for obtaining user information, we also need to print logs related to the user information, so the statement for printing logs can be encapsulated in a separate function:

var getUserInfo = function(){
  ajax( 'http:// xxx.com/userInfo', function( data ){
    console.log( 'userId: ' + data.userId );
    console.log( 'userName: ' + data.userName );
    console.log( 'nickName: ' + data.nickName );
  });
};

To:

var getUserInfo = function(){
  ajax( 'http:// xxx.com/userInfo', function( data ){
    printDetails( data );
  });
};

var printDetails = function( data ){
  console.log( 'userId: ' + data.userId );
  console.log( 'userName: ' + data.userName );
  console.log( 'nickName: ' + data.nickName );
};

2. Merge duplicate conditional snippets

If a function has some conditional branch statements in its body, and there are some duplicate codes scattered inside these conditional branch statements, it is necessary to merge and remove duplicate codes. Suppose we have a paging function paging, which receives a parameter currPage, which represents the page number to be jumped. Before jumping, in order to prevent currPage from passing in too small or too large numbers, we need to manually correct its value, as shown in the following pseudo code:

var paging = function( currPage ){
  if ( currPage <= 0 ) {
    currPage = 0;
    jump( currPage ); // jump }else if ( currPage >= totalPage ){
    currPage = totalPage;
    jump( currPage ); // jump }else{
    jump( currPage ); // jump }
};

As you can see, the code jump(currPage) responsible for jumping appears in each conditional branch, so this code can be separated out:

var paging = function( currPage ){
  if ( currPage <= 0 ) {
    currPage = 0;
  }else if ( currPage >= totalPage ){
    currPage = totalPage;
  }
  jump( currPage ); // separate the jump function };

3. Extract conditional branch statements into functions

In programming, complex conditional branch statements are an important reason why programs are difficult to read and understand, and can easily lead to a large function. Suppose there is a requirement to write a getPrice function to calculate the price of a product. The calculation of the product has only one rule: if it is summer, all products will be sold at a 20% discount. The code is as follows:

var getPrice = function( price ) {
var date = new Date();
if ( date.getMonth() >= 6 && date.getMonth() <= 9 ){ // Summer return price * 0.8;
}
return price;
};

Observe this code:

if ( date.getMonth() >= 6 && date.getMonth() <= 9 ){
// ...
}

The meaning of this code is very simple, which is to determine whether it is summer (July to October). Although this code is short, there is still some distance between the intention expressed by the code and the code itself. People who read the code must spend more effort to understand the intention it conveys. In fact, this code can be refined into a separate function, which can not only express the meaning of the code more accurately, but also the function name itself can serve as a comment. The code is as follows:

var isSummer = function(){
  var date = new Date();
  return date.getMonth() >= 6 && date.getMonth() <= 9;
};

var getPrice = function( price ) {
  if ( isSummer() ){ // Summer return price * 0.8;
  }
  return price;
};

4. Use loops appropriately

In the function body, if some codes are actually responsible for some repetitive work, then the rational use of loops can not only complete the same function, but also reduce the amount of code. Below is a piece of code to create an XHR object. To simplify the example, we only consider IE browsers below version 9. The code is as follows:

var createXHR = function(){
  var xhr;
  try{
    xhr = new ActiveXObject( 'MSXML2.XMLHttp.6.0' );
  }catch(e){
    try{
      xhr = new ActiveXObject( 'MSXML2.XMLHttp.3.0' );
    }catch(e){
      xhr = new ActiveXObject( 'MSXML2.XMLHttp' );
    }
  }
  return xhr;
};

var xhr = createXHR();
``
Now we can use loops flexibly to get the same effect as the above code:
```js
var createXHR = function(){
var versions = [ 'MSXML2.XMLHttp.6.0ddd', 'MSXML2.XMLHttp.3.0', 'MSXML2.XMLHttp' ];
  for ( var i = 0, version; version = versions[ i++ ]; ){
    try{
      return new ActiveXObject( version );
    }catch(e){

    }
  }
};

var xhr = createXHR();

5. Exit the function early instead of nesting conditional branches

Many programmers have this idea: "Each function can only have one entry and one exit." Modern programming languages ​​limit functions to only one entry. But there are often some different opinions about "a function has only one exit".

The following pseudocode is a typical code that complies with the "function has only one exit" rule:

var del = function( obj ){
  var ret;
  if ( !obj.isReadOnly ){ // Can only be deleted if it is not read-only if ( obj.isFolder ){ // If it is a folder ret = deleteFolder( obj );
    }else if ( obj.isFile ){ // If it is a file ret = deleteFile( obj );
    }
  }
  return ret;
};

Nested conditional branch statements are definitely a nightmare for code maintainers. For people who read the code, nested if and else statements are more difficult to read and understand than flat if and else statements. Sometimes the left bracket and right bracket of an outer if branch are 500 meters apart. In the words of "Refactoring", nested conditional branches are often written by programmers who firmly believe that "each function can only have one exit". But in reality, if you are not interested in the rest of the function, you should exit immediately. Directing readers to look at some useless else sections will only hinder their understanding of the program.

So we can select some conditional branches and let the function exit immediately after entering these conditional branches. To do this, there is a common trick, that is, when faced with a nested if branch, we can reverse the outer if expression. The reconstructed del function is as follows:

var del = function( obj ){
  if ( obj.isReadOnly ){ // Invert if expression return;
  }
  if ( obj.isFolder ) {
    return deleteFolder( obj );
  }
  if ( obj.isFile ) {
    return deleteFile( obj );
  }
};

6. Pass object parameters instead of long parameter lists

Sometimes a function may receive multiple parameters, and the more parameters there are, the more difficult the function is to understand and use. Anyone who uses this function must first understand the meaning of all the parameters. When using it, one must be careful to avoid missing a parameter or reversing the positions of two parameters. If we want to add a new parameter between the third and fourth parameters, it will involve a lot of code modifications, the code is as follows:

var setUserInfo = function( id, name, address, sex, mobile, qq ){
  console.log( 'id= ' + id );
  console.log( 'name= ' +name );
  console.log( 'address= ' + address );
  console.log( 'sex= ' + sex );
  console.log( 'mobile= ' + mobile );
  console.log( 'qq= ' + qq );
};

setUserInfo( 1314, 'sven', 'shenzhen', 'male', '137********', 377876679 );

At this time, we can put all the parameters into an object, and then pass the object into the setUserInfo function. The data required by the setUserInfo function can be obtained from the object by itself. Now you don't need to worry about the number and order of parameters, just make sure the key values ​​corresponding to the parameters remain unchanged:

var setUserInfo = function( obj ){
  console.log( 'id= ' + obj.id );
  console.log( 'name= ' + obj.name );
  console.log( 'address= ' + obj.address );
  console.log( 'sex= ' + obj.sex );
  console.log( 'mobile= ' + obj.mobile );
  console.log( 'qq= ' + obj.qq );
};

setUserInfo({
  id: 1314,
  name: 'sven',
  address: 'shenzhen',
  sex: 'male',
  mobile: '137********',
  QQ: 377876679
});

7. Minimize the number of parameters

If you need to pass in multiple parameters when calling a function, then this function is daunting. We must figure out what these parameters represent and must carefully pass them into the function in order. If a function can be used without passing in any parameters, this kind of function is very popular. In actual development, passing parameters to functions is inevitable, but we should try to reduce the number of parameters received by the function. Here is a very simple example. There is a drawing function draw, which can only draw a square now. It receives three parameters, namely the width, height and square of the figure:

var draw = function( width, height, square ){};

But in fact the area of ​​the square can be calculated from the width and height, so we can remove the parameter square from the draw function:

var draw = function(width, height){
  var square = width * height;
};

Assuming that this draw function starts to support drawing circles in the future, we need to replace the parameters width and height with the radius radius. However, the area square of the figure should never be passed in by the client, but should be calculated inside the draw function by adding certain rules to the passed in parameters. At this point, we can use the strategy pattern to make the draw function a function that supports drawing multiple graphics.

8. Avoid using ternary operators

Some programmers like to use ternary operators on a large scale to replace traditional if and else statements. The reason is that the ternary operator has high performance and requires little code. However, both of these reasons are difficult to sustain.

Even if we assume that the ternary operator is really more efficient than if and else, this difference is completely negligible. In actual development, even if a piece of code is looped one million times, the time overhead of using the ternary operator is at the same level as that of using if and else.
Likewise, the amount of code saved by the ternary operator is negligible compared to the loss in code readability and maintainability. There are many ways to make JS files load faster, such as compression, caching, using CDN and different domain names. Focusing only on the number of characters saved by using the ternary operator is like a 300-pound person blaming his or her weight on dandruff.

If the conditional branch logic is simple and clear, there is no problem in using the ternary operator:

var global = typeof window !== "undefined" ? window : this;

But if the conditional branch logic is very complex, as shown in the following code, then our best choice is to write if and else step by step. The if and else statements have many advantages. First, they are relatively easy to read. Second, they are easier to modify than modifying the code around the ternary operator:

if ( !aup || !bup ) {
  return a === doc ? -1 :
    b === doc ? 1 :
    aup ? -1 :
    bup ? 1 :
    sortInput ?
    ( indexOf.call( sortInput, a ) - indexOf.call( sortInput, b ) ) :
    0;
}

9. Use chain calls properly

Programmers who often use jQuery are quite accustomed to chaining method calls. In JavaScript, it is easy to implement chained method calls, that is, to return the object itself after the method call is completed, as shown in the following code:

var User = function(){
  this.id = null;
  this.name = null;
};

User.prototype.setId = function( id ){
  this.id = id;
  return this;
};

User.prototype.setName = function( name ){
  this.name = name;
  return this;
};

console.log( new User().setId( 1314 ).setName( 'sven' ) );

or:

var User = {
  id: null,
  name: null,
  setId: function( id ) {
    this.id = id;
    return this;
  },
  setName: function( name ){
    this.name = name;
    return this;
  }
};

console.log( User.setId( 1314 ).setName( 'sven' ) );

Using the chain call method does not cause too much reading difficulty, and it can indeed save some characters and intermediate variables, but the number of characters saved is also negligible. The disadvantage of chain calls is that they are very inconvenient during debugging. If we know that an error has occurred in a chain, we must first disassemble the chain to add some debugging logs or breakpoints to locate the error.

If the structure of the chain is relatively stable and not easily modified later, then there is nothing wrong with using chain calls. However, if the chain is prone to change, which makes debugging and maintenance difficult, it is recommended to use the normal call form:

var user = new User();

user.setId( 1314 );
user.setName( 'sven' );

10. Break down large classes

In the first version of the HTML5 version of Street Fighter, the Spirit class responsible for creating game characters is very large. It is not only responsible for creating character sprites, but also includes the character's attack, defense and other action methods. The code is as follows:

var Spirit = function( name ){
  this.name = name;
};

Spirit.prototype.attack = function( type ){ // Attack if ( type === 'waveBoxing' ){
    console.log( this.name + ': Use Hadouken' );
  }else if( type === 'whirlKick' ){
    console.log( this.name + ': Use whirlwind kick' );
  }
};

var spirit = new Spirit( 'RYU' );

spirit.attack( 'waveBoxing' ); // Output: RYU: Use Hadouken spirit.attack( 'whirlKick' ); // Output: RYU: Use WhirlKick

It was later discovered that the implementation of the Spirit.prototype.attack method was too large, and in fact it was completely necessary to have it as a separate class. Object-oriented design encourages distributing behavior across a reasonable number of smaller objects:

var Attack = function( spirit ){
  this.spirit = spirit;
};

Attack.prototype.start = function( type ){
  return this.list[ type ].call( this );
};

Attack.prototype.list = {
  waveBoxing: function(){
    console.log( this.spirit.name + ': Use Hadouken' );
  },
  whirlKick: function(){
    console.log( this.spirit.name + ': Use whirlwind kick' );
  }
};

The Spirit class is now much simpler and no longer includes a variety of attack methods. Instead, it delegates the attack actions to objects of the Attack class. This code is also an application of the strategy pattern:

var Spirit = function( name ){
  this.name = name;
  this.attackObj = new Attack( this );
};

Spirit.prototype.attack = function( type ){ // Attack this.attackObj.start( type );
};

var spirit = new Spirit( 'RYU' );

spirit.attack( 'waveBoxing' ); // Output: RYU: Use Hadouken spirit.attack( 'whirlKick' ); // Output: RYU: Use Whirlwind

11. Use return to exit multiple loops

Suppose there is a double loop statement in the function body, and we need to judge in the inner loop and exit the outer loop when a certain critical condition is reached. Most of the time we introduce a control flag variable:

var func = function(){
  var flag = false;
  for ( var i = 0; i < 10; i++ ) {
    for ( var j = 0; j < 10; j++ ) {
      if ( i * j >30 ){
        flag = true;
        break;
      }
    }
    if ( flag === true ) {
      break;
    }
  }
};

The second approach is to set the loop flag:

var func = function(){
  outerloop:
  for ( var i = 0; i < 10; i++ ) {
    innerloop:
    for ( var j = 0; j < 10; j++ ) {
      if ( i * j >30 ){
        break outerloop;
      }
    }
  }
};

Both of these approaches are undoubtedly dizzying, and a simpler approach is to simply exit the entire method when you need to terminate the loop:

var func = function(){
  for ( var i = 0; i < 10; i++ ) {
    for ( var j = 0; j < 10; j++ ) {
      if ( i * j >30 ){
        return;
      }
    }
  }
};

Of course, using return to exit the method directly will bring a problem. What if there is some code to be executed after the loop? If we exit the entire method early, this code will not get a chance to be executed:

var func = function(){
  for ( var i = 0; i < 10; i++ ) {
    for ( var j = 0; j < 10; j++ ) {
      if ( i * j >30 ){
        return;
      }
    }
  }
  console.log( i ); // This code has no chance to be executed};

To solve this problem, we can put the code after the loop after the return. If there are a lot of codes, they should be refined into a separate function:

var print = function( i ){
  console.log( i );
};

var func = function(){
  for ( var i = 0; i < 10; i++ ) {
    for ( var j = 0; j < 10; j++ ) {
      if ( i * j >30 ){
        return print( i );
      }
    }
  }
};

func();

This concludes this article on 11 amazing JavaScript code refactoring best practices. For more relevant JavaScript code refactoring content, please search for previous articles on 123WORDPRESS.COM or continue to browse the related articles below. I hope you will support 123WORDPRESS.COM in the future!