Preamble: The next step is to open up a small volume of knowledge about best practices for applets, which are used as a starting point, but by no means limited to this. There will be several chapters “Naming,” “Single Test,” “Code Style,” “Comments,” “Safe Production,” “Refactoring,” “Code Design,” “Performance,” “Internationalization,” and “Why Applets Development Best Practices.” Each will contain positive and negative examples and detailed explanations.

The examples in this article are typical problems found during CR. Hopefully, you will be able to avoid such problems in advance with this booklet and focus our CR more on business logic rather than such trivialities or lack of basic ideas, resulting in a high quality CR.

Code Style article 💅🏻

Code style is critical and can be visually focused, small but rewarding changes that significantly improve readability. This article focuses on styles that don’t work with the Lint specification or need to be focused on, on top of existing team ESLint.

block

Logically irrelevant code should be separated by blank lines. Make the decoupling of code logic visually visible: here is a piece, deleting this piece does not affect the previous piece, the two pieces can be understood independently, decoupled from each other, and even later refactorings can separate themselves into functions. Secondly, in Vim mode, press {or} to move blocks, which is convenient to quickly browse the blocks with tighter code logic.

💡 Tips: Follow the principle “Good code is code that is easy to delete.”

Recommended chunking or grouping rules:

• Import (Partite modules and local modules can also be grouped)
• Variable declarations (const lets can also be grouped)
• If while for etc control flow
• The return. Because return is a key word that affects code execution and understanding, it can be highlighted by a blank line
• Comments need to be preceded by blank lines. Comments and annotated code do not need blank lines
• Different functional blocks
• Branches are required between components in a View
• There are lines between one style block and another style block in THE CSS
• And so on more, welcome to add

Team members can be forced to do so through.eslintrc.js.

{
  rules: {
    'padding-line-between-statements': [
      'error',
      { blankLine: 'always'.prev: The '*'.next: 'return' },

      { blankLine: 'always'.prev: ['const'.'let'.'var'].next: The '*' },
      { blankLine: 'any'.prev: ['const'.'let'.'var'].next: ['const'.'let'.'var'] {},blankLine: 'always'.prev: ['function'.'if'.'for'.'while'.'case'.'default'.'try'.'throw'.'class'.'do'].next: The '*'}, {blankLine: 'always'.prev: The '*'.next: ['function'.'if'.'for'.'while'.'case'.'default'.'try'.'throw'.'class'.'do'],},],},};Copy the code

Bad

Three pieces of code that deal with different problems.

function jump() {
  spm.click(withdrawResultSpms.viewBill.click);
  openPage(WITHDRAW_BILL_LIST_URL);
  remoteConsole.info({ msg: 'go_billList'.url: WITHDRAW_BILL_LIST_URL });
},
Copy the code

Good

The logic of burying, jumping, and printing flow log is clearer after it is divided into three parts.

function jump() {
  spm.click(withdrawResultSpms.viewBill.click);
  
  openPage(WITHDRAW_BILL_LIST_URL);
  
  remoteConsole.info({ msg: 'go_billList'.url: WITHDRAW_BILL_LIST_URL });
}
Copy the code

Good

Visual separation of variable declaration, usage, and log reporting also makes logic clearer 👍

onRenderSuccess(res) {
  const { detail } = res || {};
  const height = detail.height || 0;
  
  this.setData({ showCdpBanner:!!!!! height }); rc.info({msg: 'onRenderSuccess cdp spaceCode: XYZ'.response: res,
  });
}
Copy the code

axml

Property branch

Suggest three attributes above the branch. Git diff will only display the modified line if you modify or add an attribute separately later.

Attribute order

HTML attributes refer to the industry attribute sequence. The order rules for axML specific attributes are as follows:

1. Conditional judgment instructions are in the first place

When viewing AXML files, conditional judgments (A :if, a:else) must be placed in a prominent position to be more intuitive, otherwise it will increase the reading cost.

Bad

<view>
  <view
    data="{{... }}"
    .
    a:if="{{ visible }}"
    onTap="onTap">.</view>
  <view
    data="{{... }}"
    a:else
    onTap="onTap">.</view>
</view>
Copy the code

As you read the code, you might look a long way before realizing that the elements you are currently analyzing are not displayed in a business scenario

Good

Just follow it under the label name, and the logic is clear

<view>
  <view
    a:if="{{ visible }}"
    data="{{... }}"
    onTap="onTap"
    >.</view>
  <view
    a:else
    data="{{... }}"
    onTap="onTap"
    >.</view>
</view>
Copy the code