This article belongs to the original article, please indicate -- from Taoyuan Xiaopan's blog

preface

Although this series is a front-end specification, my understanding is slightly different.

• Code format: specific to line breaks, symbols, spaces and other details

• Code specification: be sure to do this
• Best practice: it's best to do this

Naturally, the code format is for prettier to do.

This series is a combination of code specifications and some of the easiest to implement best practices.

1. Give priority to es6 + new syntax

• Destructuring assignment
• Class class

• Arrow function

  • Function parameter defaults
  • Optional chain

Only some features are listed. The syntax of es6 + is more expressive. If you haven't learned or are not used to it.

Then force yourself to learn and get used to it, and then you like it.

2. Multiple lines of comments must be added to the function

Exception: lifecycle functions

/**
 * Initiate batch processing
 */
function launchBatch() {
  batching.value = true
}

In fact, the best annotation relies on method naming and method parameter naming to express meaning.

But the reality is that the situation of each team is different, and the English quality of Chinese people is generally not good, so we can't just rely on naming methods.

Therefore, we stipulated in the first version of the specification that if individuals in development think that the function name is not easy to understand, they need to add comments. If the function parameter values are diverse, comments are also required.

However, the real situation is that everyone feels that their function names are easy to understand, so there are few comments. Therefore, this time, all functions are required to be annotated.

3. The function length is generally controlled within 20 lines

Why 20 lines? Combine a variety of factors. Personal experience, ease of maintenance and modularity.

In fact, line 20 is a wind vane. If it is line 21, is this code bad?

Of course not. This specification is to remind every developer to re-examine this code when it exceeds 20 lines.

Of course, some code is not good even if it is within 10 lines.

4. If there are more than two function parameters, they can be changed to parameter objects

const item = await getItemFromCollection(54391, 'shop')

// better
const item = await getItemFromCollection({
  id: 54391,
  collectionName: 'shop',
})

async function getItemFromCollection({ id, collectionName }) {
  // do something
}

The method of parameter object makes it easier to understand the meaning of parameters from the perspective of the caller. It is equivalent to helping us name parameters here. Otherwise, we have to go to the place where the function is defined and check the relevant description.

5. Function parameters should not be defined as boolean type

6. Try not to use switch case

7. Replace nested conditional expressions with guard statements

// bad
function getPayAmount() {
  let result
  if (isDead) {
    result = deadAmount()
  } else {
    if (isSeparated) {
      result = separatedAmount()
    } else {
      if (isRetired) {
        result = retiredAmount()
      } else {
        result = normalPayAmount()
      }
    }
  }
  return result
}

// good
function getPayAmount() {
  if (isDead) {
    return deadAmount()
  }
  if (isSeparated) {
    return separatedAmount()
  }
  if (isRetired) {
    return retiredAmount()
  }
  return normalPayAmount()
}

8. Use template string for multi string splicing

// bad
const str = 'a' + 'b' + test

// good
const str = `ab${test}`

9. Iterator traversal is preferred

10. When the loop is nested three times, the complexity is O(n^3). Pay attention to performance problems

If you want to better deal with such problems, you still need partners in the group to have algorithm knowledge.

But the actual situation is usually different. Considering that many people lack algorithm knowledge, we have this one.

Still, there is no best specification, only suitable and better specifications.

11. For business-related numbers, constants need to be defined

// bad
if (type === 1) {
    // doSomething
} else if (type === 2 ) {
    // doSomething
}

// good
const MANAGER = 1
const GENERAL = 2

if (type === MANAGER) {
    // doSomething
} else if (type === GENERAL ) {
    // doSomething
}

12.this conversion naming self

13. lodash is preferred for tool functions

It is recommended to use lodash es library to optimize the volume for tree shaping of webpack.

14. Special business logic needs to add single line comments

For a special business, the situation you can usually remember varies from person to person. It is possible that you always remember this special business logic, and you may forget it in a week. Write a good record for the team and for yourself in the future.

15. Delete TODO comments as soon as possible

16. The expired code shall be deleted in time

If you really want to find it, you can check git history.

17. Delete the debug console as soon as possible Log statement

If you write a lot of debugging statements in the code, maybe the way to debug the code is not good enough. Try debugger.

18. Special circumstances

• It is appropriate to use i in the for loop
• It is appropriate to use temp in variable exchange

reference material

• Reconstruction
• Code neatness
• Ugly code