Code specification
- Use the ESLint tool to check JS code
- No lint warnings or errors.
- Without the console. The log ()
2. Routine check-ups
2.1. Code style
- Hardcoded data, const is used.
❎ if(code === 10){} ✅ const status = 10; If (code = = = status) {}.Copy the code
- Avoid too much if else and try using maps or ternary expressions
// Example 1 ❎ if (brand === 'oppo') {boss = 'Tony'} else if (brand === 'vivo') {boss = 'Leo'} ✅ let map = {oppo: 'Tony', vivo: 'Leo'} boss = map['oppo'] // Example 2 ❎ if (status) {a = 1} else {a = 2} ✅ a = status? 1:2Copy the code
- Remove unwanted comment code.
- Remove unnecessary comments.
- Add necessary comments. Necessary comments explain what the code does and why.
- Does the code conform to programming specifications? (Position of braces, variable and function names, line length, indentation, formatting, and comments)
- Is the loop set to length and correct termination conditions?
- Is the array index within the allowed range?
- Are HTML tags written correctly, nested correctly, and closed correctly?
- Whether the variable has an initial value
- Use watch and this.$forceUpdate() as little as possible
- Project directories/APIS/routes should be as modular and semantically named as possible
2.2. ES6 | 7…
- Use the ES6 +.
- Use the arrow function. Avoid the let that | self = this.
- Use function parameter defaults.
- The use of…
- Use const let.
- Use import export.
- Use the string template.
- The arrays | objects to deconstruct the assignment.
- Using Promise | Async/Await.
- Use optional chaining as the determination condition
A && user.a.b .bCopy the code
2.3. Third-party libraries
- Use functions such as Lodash (introduced on demand) rather than self-actualization.
- Try to use the UI library already referenced by the project rather than rewriting the component.
- Whether to introduce CookUI, remove ElementUI
- Whether to use security front-end scaffolding, component libraries, common packages
2.4. The CSS
- Naming conventions. Comply with team naming rules.
- The use of SCSS
- Use flexbox.
- Avoid using! important
- Avoid inline styles. Separate content from design for easier maintenance.
- Define some global styles for easy use
2.5. The annotation
- Are there appropriate comments around important features?
- Does the important function comment contain the relevant function description? (Input, output, function, etc.)
- Can you infer from the comments what the following code does?
- Does TODO still exist in the code? Can features be removed or improved?
- Do you leave instructions where accidents may occur
3. Code quality
- Does the code work?
- Is there useless debugging code?
- Whether the console has an obvious error
- Is the code easy to understand and logical? Whether the redundant
- Is the code as modular as possible?
- Is it as componentized as possible
- Whether the timer is eliminated with the life cycle
- Whether component destruction removes listeners
- Whether to delete unused installation packages from NPM
- Interface requests must use async await
- More than two parameters can be converted to object parameters, otherwise a method parameter to increase the maintainability of the code
- There is no error handling, such as sending request data when the network is abnormal
- Use async/await asynchronous requests with try/catch synchronously
- Parse () is used synchronously with a try/catch conversion
- Make use of environment profiles and global constants
- Implicit conversions are used for conditional judgment
- After the data is obtained, it is processed and then assigned
- If a value cannot be null, whether a default value is set in advance
Data: {name: 'not logged in'} person? .name && (name = person.name)Copy the code
4. Safety check
- Are all pages where users can enter information filtered against XSS and special characters? (XSS attack Defense)
- Are all data inputs checked (for correct type, length, format, and range) and encoded? (Form verification)
- The front end checks whether the return from the interface is valid and correct.
- When developing code related to DOM manipulation, do you deal with cases where the DOM does not exist or has been artificially modified?
- When retrieving data and information, are types processed, converted and set to null default values?
- Is error handling logic written in all the places where errors can occur? For example, block execution, display error messages, and record error logs and information.
- Are XSS characters filtered in the code where window.location attributes are retrieved?
- Are the output values checked and encoded?
- Can invalid parameter values be handled?
- No permission or access error is 404 accessed? (Later unified 404 page)
5. Performance check
- Localstorage usage issues (to be added)
- Whether the button is throttling or anti-shaking
- Is the JS code at the bottom as far as possible? Is the CSS code at the top as much as possible?
- Is the CDN deployed or the caching function enabled?
- Are static resources packed and compressed before going live or published? (webpack)
- Correct use of preloading, lazy loading and other techniques to improve performance.
- Are images and other resources compressed?
- Loop lengths are cached ahead of time
Const a = [1,2,3,4,5] ❎ for (let I = 0; i < a.length; I ++) {} ✅ const len = a.length for (let I = 0; i < len; i++) {}Copy the code
- The loop ends as early as possible
- SetInterval is used with setTimeout when lists need to be polled
- Interfaces are invoked within Created as much as possible