class=”markdown_views prism-atom-one-dark”>

Front-end code specification

Front Standard Guide

Front-end JS project development specification

The purpose of the specification is to write high-quality code, so that your team members are happy every day, and everyone is happy together.

Quoted from the opening paragraph of “Ali Statute”:

—-The complexity of modern software architecture requires collaborative development, how to efficiently collaborate? There is no circle without rules, and it is difficult to coordinate without norms. For example, the formulation of traffic regulations is to restrict driving rights on the surface, but in fact it is to protect the personal safety of the public. Imagine if there is no speed limit and no traffic lights, who would dare to drive on the road. For software, appropriate norms and standards are by no means to eliminate the creativity and elegance of code content, but to limit excessive personalization, work together in a generally recognized and unified way, improve collaboration efficiency, and reduce communication costs. The blood flowing between the lines of the code is the blood of the software system. The improvement of quality is to minimize pitfalls as much as possible, eliminate repeated pitfalls, and effectively improve system stability and code quality.

For more information, please refer to w3c front-end development specification

1. Programming rules

(1) Naming convention

1.1.1 Project Naming

All in lowercase, separated by dashes.

Positive example: mall-management-system

Counterexample: mall_management-system / mallManagementSystem

1.1.2 Directory naming

Use all lowercase, separated by a dash, when there is a plural structure, use plural nomenclature, abbreviations do not need plurals

Example: scripts / styles / components / images / utils / layouts / demo-styles / demo-scripts / img / doc

Counterexample: script / style / demo_scripts / demoStyles / imgs / docs

[Special] The component directory in components in the VUE project, named with kebab-case

Positive example: head-search / page-loading / authorized / notice-icon

Counterexample: HeadSearch / PageLoading

[Special] All directories in the VUE project except the components directory are also named with kebab-case
Positive example: page-one / shopping-car / user-management

Counterexample: ShoppingCar / UserManagement

1.1.3 JS, CSS, SCSS, HTML, PNG file naming

All in lowercase, separated by dashes

Positive example: render-dom.js / signup.css / index.html / company-logo.png

Counterexample: renderDom.js / UserManagement.html

1.1.4 Naming rigor

It is strictly forbidden to use pinyin and English in the naming of the code, and it is not allowed to use Chinese directly. Note: Correct English spelling and grammar can make it easy for readers to understand and avoid ambiguity. Note that even if the naming method is purely pinyin, avoid using

Example: henan / luoyang / rmb and other international names can be regarded as English.

Counterexample: DaZhePromotion [discount] / getPingfenByName() [score] / int variable = 3

Put an end to completely non-standard abbreviations to avoid ignorance of the meaning:

Counterexample: The “abbreviation” of AbstractClass is named AbsClass; the “abbreviation” of condition is named condi. Such random abbreviations seriously reduce the readability of the code.

(2) HTML specification (Vue Template is also applicable)

1.2.1 HTML type

It is recommended to use HTML5 document type statement: .
(It is recommended to use HTML in text/html format. Avoid using XHTML. XHTML and its attributes, such as application/xhtml+xml, are supported and optimized in browsers space is very limited).

Specify character encoding
IE Compatibility Mode
Specify character encoding
doctype uppercase

Positive example:


 
   
     
     
     Page title

1.2.2 Indentation

Use 2 spaces (a tab) for indentation

Nested nodes should be indented.

1.2.3 Block comments

Add a pair of HTML comments after each block element, list element and table element. Note format

Positive example:

<body
   <span class="token commbe consistent.  
 
 Positive example:
 Backend url: EmployeeController.java
 /employee/add
 /employee/delete/{id}
 /employee/update
 
Frontend: employee.js
 // add employee
   addEmployee: (data) => {
     return postAxios('/employee/add', data)
   },
   // Update employee information
   updateEmployee: (data) => {
     return postAxios('/employee/update', data)
   },
     // delete employee
   deleteEmployee: (employeeId) => {
     return postAxios('/employee/delete/' + employeeId)
    },
 
2) assets directory
Assets are static resources, which store images, styles, icons and other static resources. The static resource naming format is kebab-case
|assets
 |-- icons
 |-- images
 | |-- background-color.png
 | |-- upload-header.png
 |-- styles
 
3) components directory
This directory should be divided into directories according to components. The directory is named KebabCase, and the component naming rule is also KebabCase
|components
 |-- error-log
 | |-- index.vue
 | |-- index.less
 |-- markdown editor
 | |-- index.vue
 | |-- index.js
 |-- kebab-case
 
4) constants directory
This directory stores all the constants of the project. If the constants are used in vue, please use the vue-enum plugin (https://www.npmjs.com/package/vue-enum)
Directory structure:
|constants
 |-- index.js
 |-- role.js
 |-- employee.js
 
Example: employee.js
export const EMPLOYEE_STATUS = {
   NORMAL: {
     value: 1,
     desc: 'normal'
   },
   DISABLED: {
     value: 1,
     desc: 'disabled'
   },
   DELETED: {
     value: 2,
     desc: 'Deleted'
   }
 };

 export const EMPLOYEE_ACCOUNT_TYPE = {
   QQ: {
     value: 1,
     desc: 'QQ login'
   },
   WECHAT: {
     value: 2,
     desc: 'WeChat login'
   },
   DINGDING: {
     value: 3,
     desc: 'DingTalk login'
   },
   USERNAME: {
     value: 4,
     desc: 'Username and password login'
   }
 };

 export default {
   EMPLOYEE_STATUS,
   EMPLOYEE_ACCOUNT_TYPE
 };
 
5) router and store directories
These two directories must split the business and cannot be put into one js file.  
router try to keep consistent with the structure in views
store splits different js files according to business
6) views directory

The naming should be consistent with the backend, router, api, etc.
Components in components should use PascalCase rules

|-- views view directory
 | |-- role role module name
 | | |-- role-list.vue role list page
 | | |-- role-add.vue role new page
 | | |-- role-update.vue role update page
 | | |-- index.less role module style
 | | |-- components role module common component folder
 | | | |-- role-header.vue role header component
 | | | |-- role-modal.vue role pop-up box component
 | |-- employee employee module
 | |-- behavior-log behavior log log module
 | |-- code-generator code generator module
 
2.2.4 Notes
Sort out where comments must be added

Instructions for using public components
The interface js file in the api directory must be commented
The state, mutation, action, etc. in the store must be commented
The template in the vue file must be commented, if the file is larger, add start end comment
The methods of the vue file, each method must add a comment
In the data of the vue file, uncommon words should be commented

2.2.5 Other
1) Try not to manipulate the DOM manually
Because the vue framework is used, try to use vue's data-driven update DOM in project development, and try (unless it is a last resort) not to manually manipulate the DOM, including: adding, deleting, modifying dom elements, changing styles, adding events, etc.  
2) Remove dead code
Due to the use of code version tools such as git/svn, useless code must be deleted in time, for example: some debugging console statements, useless deprecated function code.

Front-end code specification_Luck Young’s blog

Front-end code specification

Front-end JS project development specification