I found that there was very little discussion among the front-end students about the great book of software engineering called “The Code Clean Way”, and some front-end students in the team didn’t even know this book for many years. Maybe there are too many front-end things to learn, plus the flexibility of JS itself, resulting in code cleanliness seems not so important. Value people, also often lack practice or do not know how to practice. This article summarizes some of my own experiences, as well as some blogs, and puts together a guide to JS/TS code. If you are interested, please refer to my other blog post: SOLID Principles and Practices – Nuggets (juejin. Cn)

The variable name

  1. The team can define it internally, and appropriate variable names should make it easy to understand and maintain. Example:

    CurrentDate over time TMP over meaningless named constants like S/A /b in all uppercaseCopy the code

  2. Keep names consistent. For example, if the user is related, everyone starts with user, such as userInfo, userName, etc

  3. Don’t use magic numbers use constants instead of magic numbers

  4. Don’t use too much context for example

    class User{
  name:string
 }
Copy the code

    Better than

    class User{
userName:string
}
Copy the code

  5. Reduce useless variables like

     return createUser();
 const user  = createUer();
 return user;
Copy the code

function

  1. A proper function name is the same as a variable name. A function name needs to intuitively explain what the function does. For example: getCurrentDay We can also use fixed prefixes such as:
    1. Sending service requests can be named requestXXX,
    2. Submit data like server can be named submitXXX,
    3. Functions that have no arguments but return values can be named getXXX,
    4. A function that creates a new object can be named createXX,
    5. Functions that take arguments but return no value can be named handlerXXX,
    6. Functions that take arguments and return values can be named processXXX,
    7. Functions that return Boolean values can be named isXXX/hasXXX,
    8. If you make changes to the input object, you can name it updateXXX,deleteXXX, etc.
  2. Appropriate parameter defaults
function createUser(name = "nobody") {
 // ...
}
Copy the code

3. Don’t have too many arguments, otherwise you can consider splitting the function, or encapsulating the arguments. Such as

Function createUser(name = "nobody", age= "18",sex= "man",licenceId= "") {//... }Copy the code

Can be encapsulated as

Function createUser ({name = "nobody", the age = '18', sex = 'man', licenceId = '}) {/ /... } createUser({name = "congbai", age='28', sex='man', licenceId=''})Copy the code

Or we could split it into two

 const user  = createUserByName('congbai')
 user.setAge(20)
 user.setSex('man')
Copy the code
  1. Single responsibility

The difficulty here is how to define ‘responsibility’. For example, we can make ‘create user’ as one responsibility, or we can break it down into ‘Create user name, Set user age, set user gender’ three responsibilities. This depends on your business scenario. Six reference standards:

  1. If there are more than 50 lines of code in a responsibility, you can definitely split out more responsibilities.

  2. If a piece of logic is reused more than twice, it can be shared

  3. If a piece of logic has no side effects, it can be removed

  4. If there are too many judgment conditions, it can be split out

  5. If /else internal logic, try to break it out

  6. The map, reduce, foreach code snippets passed into the array can be split out

  7. Multilayer nesting must be removed, up to two layers

  8. If an argument passed inside a function is used as an if condition directly, then the if-related logic should be handled outside the function: for example:

    Function createUser (sex= 'man') {if(sex==='man') {return createMan()} else{return createWoman()}} functin getUser(){  const sex= getSex(); return createUser(sex); }Copy the code

    Can be changed to

    functin getUser(){
 const sex= getSex();
 if(sex ==='man'){
    return createMan()
 }esle{
  return createWoman()
 }
}
 
Copy the code

  9. Use es6’s deconstruction syntax to copy and assign values for example

    user={ ... anotherUser, age:28 } allUser=[...oldUser,...newUser]Copy the code

  10. Reduce the side effects of functions

    1. Avoid modifying any variables other than parameters
    2. If possible, try to return a new object rather than modifying the object in the argument.

    Such as

    function addUserToList(user,list){ user.age=19; list.push(user); Function addUserToList(user,list){return [...list,{...user,age:19}]}Copy the code

    It is possible because of the loss of performance, so it should be measured.

  11. Try to use functional programming such as arrays of foreach,filter, etc.

  12. Use polymorphism and design patterns to reduce if/else judgments and reduce coupling.

See also SOLID principles and Practices – Nuggets (juejin. Cn) 9. Use Promise instead of the callback function

Class design

  1. Use get set accessors to modify properties whenever possible
  2. Use composition more than inheritance
  3. Don’t modify the prototype if you don’t have to
  4. The set accessor can return ‘this’ for chained calls

Such as

class User { setName(name){ this.name = name; return this; } setAge(age){ this.age = age return this; }} user.setname (' mytage ').setage (28)Copy the code
  1. The order of methods in a class is best arranged in some order. For example, if B is called from A, B should come after A, making it easier to read.

other

  1. These principles are for reference, not for strict observance.

  2. There is no beautiful code that can be written once and for all, and it needs to be fixed periodically according to these principles

  3. Indentation, naming, and short coding are all guarantees of poetic beauty

  4. Proper naming can effectively reduce the need for annotations, but annotations should be made where they are. When code is reviewed, there should be annotations for all the parts that others cannot understand.