Clean front-end code

Recently read “code clean way”, quite a few points of perception. Although the original work is written for the Java language, many of the principles can be applied in the front end. The following is a personal summary of some points and feelings, and you share.

This paper only makes a summary of the part that has great relevance to the front end in the original work, which only accounts for about half of the original work. For more, please read the original.

There are no details in this article. For more detailed examples, I recommend reading clean-code-js.

Named article 🙋

The principle of 😲

• Briefly.

  • The two need to take into account, balance, simple to say, to do… have to slowly experience themselves.

• Variable name definitions use noun phrases.

     customerGender
  Copy the code

• Function names are defined using phrasal verbs.

     getCustonmerGender
  Copy the code

Rules 😡

• Avoid ambiguity.

  • The smaller the range of meaning behind the name, the better. It is best to know what it means without a comment.

        - good:  gameBoard 
        - ba d:  theList
    Copy the code

• Avoid misleading.

  • Try not to use misleading words in names. For example, don’t include a list (in case the data behind it isn’t a list structure).

        - good: accountList 
        - ba d: accountList
    Copy the code

• Avoid nonsense.

  • The obvious need not be stated.

       - good: customerGender 
       - ba d: customerGenderData
    Copy the code

• Avoid creating your own.

  • Don’t make up your own words or use acronyms you understand.

       - good: timestamp 
       - ba d: ts
    Copy the code

• Avoid inconvenient search.

  • Try not to use single-word variable names, such as days and workDays, as this makes it difficult to search accurately. WorkDays will also be matched when searching for days.

       - good: workDays 
       - ba d: days
    Copy the code

• Avoid coding.

  • Don’t make up your own words or use acronyms you understand.

       - good: product 
       - ba d: productData
     ` `` 
    
    Copy the code

• Avoid polysemy.

  • Don’t use one word for more than one meaning. For example, using handlers to indicate both additions and deletions (although at first glance this is fine).

       - good: delCustomerGender && addCustomerGender 
       - ba d: handlerCustomerGender
     ` `` 
    
    Copy the code

• Avoid using more than one word.

  • Don’t use more than one word to mean the same thing. For example, don’t use add and append at the same time to express increment.

        - good: addCustomer || appendCustomer 
        - ba d: addCustomer && appendCustomer 
      ` ``  
    
    Copy the code

Suggest 😘

• It’s never too late to change your name.

  • Replace the name as soon as you think of a better one.

• Deliberately applying naming rules.

  • At the beginning, we should apply the standard rules deliberately, and then we will be more and more handy.

• Never mind the long names.

  • Long and clear names are far better than short and vague ones.

Function article 🙋

Rules 😡

• To be short.

  • Overly long functions are hard to read and dizzying (whether you spend them or not, I do).

• To fully.

  • Each function should only do one thing. If not, break it up.

• Corresponds to an abstraction layer.

  • For two levels of processing such as table > tableHeader, separate functions are required.

• Keep the parameters as few as possible.

  • Try not to have more than three parameters.

    • If you have to use more than three parameters, consider using parameter objects or parameter lists.
    • Coriation is also a good choice.

• Don’t have side effects.

  • Functions should not change beyond their responsibilities. The checkPassword function, for example, should not change the password.

• Don’t repeat yourself.

  • If similar code appears more than twice, optimize it.

    • Similar problems occur with HTML and CSS, not just JS

Suggest 😘

• The function is within 20 lines.

  • But don’t be less for the sake of less, such as if… else… This kind of code block shrinks to a single line, which is counterproductive.

• Follow the top-down rule.

  • Write the code in logical order, not repeatedly.

• Try not to use identification parameters.

  • For example, it would be easy for the front end to encounter methods like this, where the parameter bool is passed as an identifier. Functions of this form generally do not conform to the single responsibility rule.

   / / eg:
  function changeLoadingStatus (bool) {
    if (bool){
       loadingStatus = 'open'
    }else{ 
       loadingStatus = 'close'}}// It is better to split it into:
  function openLoading (bool) {
       loadingStatus = 'open'
  }
  function closeLoading (bool) {
       loadingStatus = 'close'
  }		  
  // There is something wrong with this code.
  Copy the code

Gemara 🙋

The principle of 😲

• Comments are additions to the code, not translations.

• Don’t use comments to explain information that can be conveyed through variable names and clear code rules.

Rules 😡

• Don’t try to save poorly thought-out code by writing too many comments.
• Use comments to explain the intent behind a function.
  • Comments are better at explaining why you’re doing something than what you’re doing.
• Comments can be used not only to explain, but also to warn.
• Use a TODO annotation to indicate the processing to be done.
• Function and file annotation format should be standardized and unified.
  • You can use the vscode plug-in koroFileHeader.

Suggest 😘

• There is little need to add signature information to code comments. (Editor information can easily be obtained through source control systems such as Git or SVN.)

• It is not necessary to have a function header; a clear function name is more important than a function header comment.

Format paper 🙋

The principle of 😲

• Good formatting improves the reading experience.

Rules 😡

• Blocks are reasonably separated by blank lines.
  • This applies to HTML, CSS, and JS.
• Logically related code should also be close in distance.
• Keep a consistent indentation style.
  • Two squares or four squares, it is important to be consistent.
• Team development should pay more attention to the regularity of the format rules.

Suggest 😘

• Many of the front-end formatting issues are already tool-ready.
  • Eslint, Preitter ·, Stylelint, Vetur.

Error Handling 🙋

The principle of 😲

• Don’t mess up your code logic with error handling.

Rules 😡

• Use try-catch-finally statements wisely.
• In catch, specify the circumstances in which the exception occurred.
• Do not return or pass null.

Progressive optimization 🙋

The principle of 😲

• Clean code doesn’t happen overnight, and incremental optimization is extremely important.
  • The following rules are in order of importance:

Rules 😡

• All tests must be passed.
• Make sure there is no duplication.
• Try to express the programmer’s intention.
• Keep methods and variables as few as possible.

Suggest 😘

• Progressive optimization is not just about paying attention to the above points, but also forgetting all of our previous rules and recommendations in the process.

A mind map is attached.