This is the 15th day of my participation in Gwen Challenge

Code refactoring

Design patterns are actually refactoring code to make it easier to maintain and write. So in addition to remembering how design patterns are used and how they are used, we also need to keep in mind some code refactoring tips.

Merge repeated fragments

For repeated statements within a fragment, we can try to merge them. Examples are as follows:

const example = function(num) {
    if(num < 0) {
        num++;
        console.log(num);
    } else if(num < 10) {
        num = 10;
        console.log(num);
    } else {
        console.log(num); }}Copy the code

In the above code, we implemented a function that adds 1 below 0 to 10. We print the value of num after each execution, but obviously the log statement is repeated and can be merged together.

const example = function(num) {
    if(num < 0) {
        num++;
    } else if(num < 10) {
        num = 10;
    }
    console.log(num);
}
Copy the code

That’s a lot simpler.

Distill conditional statements into functions

Sometimes when we write business code, we will write long judgment statements. At this time, it may be several lines to write an if, which is intuitive, but people who need to read the code need to read it one by one, which is very difficult. At this time we can refine the conditional statement, give it a good name, help others to understand, but also help their own memory and subsequent changes. Examples are as follows:

const getSign = function(person) {
    const { age, sign } = person;

    if(age >= 0 && age <= 17) {
        reutrn getParentsSign(person);
    }
    return sign;
}
Copy the code

Age >= 0 && age <= 17; age >= 0 && age <= 17; If it’s a minor, we need to get the parents’ signature information. Otherwise it returns its own signature information. You can actually extract it directly, it’s more intuitive, it’s easier to reuse.

const isUnderage = function(age) {
    return age >= 0 && age <= 17;
}
const getSign = function(person) {
    const { age, sign } = person;

    if(isUnderage(age)) {
        reutrn getParentsSign(person);
    }
    return sign;
}
Copy the code

This is easier to read and reuse when rewritten.

Instead of nesting conditional branches, let the function exit early

As for if statements, there seems to be nothing programmers love more than optimizing if statements. If we nested in an if statement, we need to see if it can be tiled. Otherwise it might be very uncomfortable for the person reading the code.

const relation = function(person) {
    if(isUnderage(person.age)) { // Parents must be under age
        if(! person.father) {return isFather();
        } else if(! person.mother) {returnisMather(); }}else {
        returnisSelf(); }}Copy the code

The above code is only under age, there will be parental data in the data. At this point we can reverse the outside if statement so that we can write tiled if and else statements.

const relation = function(person) {
    if(! isUnderage(person.age)) {// Not minors directly skip
        return isSelf();
    }
    if(! person.father) {return isFather();
    } else if(! person.mother) {returnisMather(); }}Copy the code

Exit multiple loops with return

When we write for loops, we often come across multiple nested loops that need to exit directly to the outer layer. But using the return method directly returns the entire method, making it impossible to execute subsequent code. Like this:

const exampleFor = function() {
    let a;
    for(let i = 0; i < 10; i++) {
        for(let j = 0; j < 10; j++) {
            if( i + j > 13) {
                a = i + j;
                return; }}}console.log(a); // Cannot print after return
}
Copy the code

The usual solution is to merge the looping code into a function and run it directly.

const print = function(a) {
    console.log(a);
}
const exampleFor = function() {
    let a;
    for(let i = 0; i < 10; i++) {
        for(let j = 0; j < 10; j++) {
            if( i + j > 13) {
                returnprint(i + j); }}}}Copy the code

reference

[1] Zeng: JavaScript design patterns and development practices