1. Framework usage specifications

1.1 the Vue

1.1.1 Component Naming conventions

Component names should always be multiple words (greater than or equal to 2) and named in the KebabCase format.

1.1.2 A component’s data must be a function.

When a data property is used in a component (anywhere but new Vue), its value must be a function that returns an object.

1.1.3 Prop should be defined in as much detail as possible, at least by specifying its type.

1.1.4 V-for The key must be set.

1.1.5 Do not use v-if and V-for on the same element.

1.1.6 Component Styles add scope.

1.1.7 If there are many feature elements, line breaks should be active.

1.1.8 Component templates should contain only simple expressions, and complex expressions should be refactored to evaluate properties or methods.

1.1.9 It is recommended to use abbreviations for directives (: for V-bind:, @ for V-on 🙂

1.1.10 Single-file components should always keep the label order as

<template>... </template> <script>... </script> <style>... </style>Copy the code

1.1.11 If you need to switch frequently, run v-show. If conditions rarely change at run time, use V-if.

2. Technical specifications

2.1 Naming Conventions

2.1.1 All project names shall be lowercase and separated by hyphens.

2.1.2 Directories are named in lowercase letters and separated by hyphens (-). If the directory has a plural structure, use the plural naming method and do not use the plural abbreviation.

2.1.3 Names of JS, CSS, SCSS, HTML and PNG files are all lowercase and separated by hyphens.

2.1.4 CSS class names are lowercase letters separated by hyphens, IDS are named in camel shape, and variables, functions, mixers, and placeholder are named in camel shape.

2.1.5 JS method names, parameter names, member variables, and local variables all use the lowerCamelCase style and must follow the hump form. Method must be named as a verb or verb + noun. You can use add/update/delete/detail/get.

2.2 Code writing specifications

Use two Spaces for indentation, and insert a blank line between different logic, different semantics, different business code to improve readability. Do not use conditional judgments if you can use trigonometric and logical operators, but remember not to write too long trigonometric operators. If there are more than 3 layers please split the function and write clear comments.

2.3 Annotation Specification

2.3.1 Suggested comments:

  • After each block element, list element, and table element, add a pair of HTML comments
  • Usage instructions for common components
  • The interface JS files in the API directory must be annotated
  • State, mutation, action, etc. in store must be commented
  • Template in the vue file must be commented, or start end if the file is large
  • Vue file methods, each method must be commented
  • Vue file data, very see words to annotate

2.3.2 Function Notes:

/** ** begins with an asterisk, followed by a space, First behavior function description * @ param} {type parameters of separate type * @ param {} [type | | type] parameters multiple types of * @ param type {} [optional] parameters optional parameters with [] wrapped up * @ the return type of {} * @author create time modify time (short date) change other code to leave name * @example (if necessary) */Copy the code

2.3.3 File Header Comments:

The VScode file header automatically generates comments: koroFileHeader

2.4 HTML Tag Usage Specifications

  • Self-closing labels do not need to be closed (for example, IMG Input BR HR). Optional closing tag, which must be closed (for example:</li> 或 </body> )
  • Minimize the number of labels
  • Add viewPort for mobile devices

2.5 CSS style specifications

  • Avoid label names in CSS selectors
  • Precedence is given to child selectors
  • Omit the units after 0
  • Organize in the following order: @import; Variable declaration; Style declaration;

3. The Git specification

3.1 Submit the code in the following order

git stash 
git pull
git stash pop
git add .
git commit -m xxx
git push
Copy the code

3.2 Commit Annotation specification

Git commit -m '<type>(<scope>): <subject>' git commit -m 'Copy the code
  • Type: branch behavior, including the following types:
  1. [New] : New function or feature
  2. [Bug fix] : Bug fix
  3. [Documentation] : File modification, such as modifying the ngDoc content of the project using ngDoc
  4. [Interface] : Format modification. Such as changing indentation, Spaces, removing extra blank lines, and filling in missing semicolons. In short, changes that do not affect the meaning and functionality of the code
  5. Refactoring: Code refactoring. Code changes that do not fix bugs or add new features
  6. [Optimization] : Improve code performance
  7. [Test] : Test file modification
  8. [Other] : Other minor changes. Typically a change of just one or two lines, or a small change committed several times in a row
  • Scope: Indicates the scope of the commit’s impact, which can vary from scenario to project
  • Subject: A short description of the commit purpose