1. Herramienta de verificación de código estático front-end
1.1 ESLint: ESLint es una herramienta de inspección de código JavaScript de complemento que puede usar complementos de reglas o reglas personalizadas para realizar una inspección estática en el código.
1.2, JSLint: JSLint es una herramienta de inspección de código JavaScript muy popular desarrollada por Douglas Crockford, que puede ayudar a los desarrolladores a comprobar posibles problemas en el código.
1.3 JSHint: JSHint es una rama de JSLint, que admite opciones de configuración más flexibles y proporciona mensajes de error más amigables.
1.4, TSLint: es una herramienta de calidad de código TypeScript, similar a ESLint, que admite complementos y reglas personalizadas.
1.5 Más bonito: es una herramienta de formato de código que admite varios idiomas y editores, y puede formatear automáticamente el código para que el estilo del código sea uniforme.
1.6 Stylelint: Stylelint es una herramienta de inspección estática especialmente utilizada para CSS, que puede verificar si el código CSS se ajusta a ciertas especificaciones y estilos.
1.7, TypeScript: TypeScript es un lenguaje de programación de código abierto que se puede utilizar para desarrollar aplicaciones de JavaScript grandes y complejas. Proporciona funciones como verificación de tipos, análisis estático y sugerencias de código para ayudar a los desarrolladores a escribir un código más sólido y fácil de mantener.
Las herramientas anteriores pueden ayudar a verificar la calidad del código, mejorar la capacidad de mantenimiento y la legibilidad del código, se recomienda elegir la herramienta adecuada de acuerdo con los requisitos del proyecto.
2. Las siguientes son algunas especificaciones comunes de revisión de código front-end
2.1 Formato del código: el código debe tener un formato determinado para mejorar la legibilidad y el mantenimiento. Por ejemplo, use espacios para alinear el código, use sangría para indicar bloques de código, etc.
2.2 Nomenclatura de variables: las variables, los nombres de funciones, las constantes, etc., deben ser significativos, claros y fáciles de entender, y coherentes con el significado real que representan.
2.3 Especificación de comentarios: los comentarios deben agregarse adecuadamente al código. Los comentarios deben ser claros y claros, cubriendo la información clave del código, y no deben ser demasiado o demasiado poco.
2.4 Pruebas y manejo de errores: el código debe tener suficientes mecanismos de manejo de errores y también debe estar equipado con los casos de prueba correspondientes para garantizar la calidad del código.
2.5 Optimización del rendimiento: el código debe optimizarse para minimizar el uso de recursos y el tiempo de carga. Por ejemplo, evite el código redundante, reduzca el tamaño del archivo, mejore el paralelismo durante la carga, etc.
Las anteriores son solo algunas especificaciones comunes de revisión de código front-end. También puede consultar varios marcos front-end, lenguajes, patrones de diseño y otros documentos relacionados para formular especificaciones de revisión coincidentes en su proyecto.
3. Las reglas de nomenclatura de las variables de JavaScript son las siguientes
3.1 Los nombres de las variables deben comenzar con una letra, un guión bajo (_) o un signo de dólar ($).
3.2 Los nombres de las variables pueden contener letras, números, guiones bajos o signos de dólar.
3.3. Los nombres de las variables no deben usar palabras reservadas de JavaScript, como si, si no, para, función, etc.
3.4 Los nombres de las variables deben usar nombres significativos para que el código sea fácil de entender y mantener.
3.5 Los nombres de las variables deben nombrarse en mayúsculas y minúsculas, es decir, la primera palabra en minúsculas y la primera letra de las siguientes palabras en mayúsculas (por ejemplo: nombre).
let userName;
let num1;
let totalAmount;
let _privateValue;
let $globalVar;
Cuarto, JavaScript evita nombres de variables redundantes
4.1 Use nombres de variables significativos: use nombres de variables significativos para evitar nombres de variables redundantes.
Por ejemplo:
use "nombre de usuario" en lugar de "nombre" para almacenar nombres de usuario.
Use const user = { name: "snow" }, no use const user = { userName: "snow" }, cuando use este objeto, es directamente user.name en lugar de user.userName.
4.2 Evite las variables globales: el uso de variables globales puede dar lugar a conflictos de nombres de variables y redundancia. Puede evitar el uso de variables globales en su código y, en su lugar, limitar las variables a funciones o módulos.
4.3 Uso del alcance: en JavaScript, cada función tiene su propio alcance. El alcance se puede utilizar para evitar la redundancia de nombres de variables. Por ejemplo, solo se puede acceder a una variable declarada dentro de una función dentro de esa función, lo que evita conflictos de nombres de variables y redundancia.
4.4 Use const y let: use const y let para evitar nombres de variables redundantes. const y let limite el alcance de las variables y proporcione una mejor seguridad y mantenibilidad del código.
4.5 Usar convenciones de nomenclatura: El uso de convenciones de nomenclatura en el código puede evitar nombres de variables redundantes. Por ejemplo, puede usar mayúsculas y minúsculas o nomenclatura de subrayado, etc.
A través de los métodos anteriores, la redundancia y el conflicto de nombres de variables en JavaScript se pueden evitar de manera efectiva y se puede mejorar la calidad y el mantenimiento del código.
5. Convención de nomenclatura CSS BEM
BEM es una convención de nomenclatura CSS de uso común. Su nombre completo es Bloque, Elemento y Modificador.
5.1 Bloque: Un bloque es un componente independiente y reutilizable que contiene uno o más elementos. Se recomienda usar una sola letra o palabra para el nombre de clase del bloque y usar un guión (-) para conectar varias palabras, por ejemplo: .menu, .list.
5.2, Elemento (Elemento): Un elemento es un componente de un bloque, solo puede pertenecer a un bloque y no puede usarse solo. El nombre de clase del elemento debe estar compuesto por el nombre de clase del bloque y una sola letra, una sola palabra o palabras, y varias palabras también están conectadas con un guión (-), por ejemplo: .menu__item, .list__item.
5.3, Modificador (Modifier): Los modificadores se utilizan para mejorar las características de los bloques o elementos, y también se pueden utilizar para expresar estados, temas, etc. El nombre de clase de un modificador debe consistir en el nombre de clase del bloque o elemento y una sola palabra o palabras, unidas por un guión (-), por ejemplo: .menu__item--active, .list__item--disabled.
El uso de convenciones de nomenclatura BEM puede hacer que el código CSS sea más legible y fácil de mantener. Al mismo tiempo, también puede reducir los conflictos de estilo innecesarios y mejorar la reutilización de los componentes.
6. Además de la convención de nomenclatura BEM, existen algunas convenciones de nomenclatura CSS comunes como las siguientes
6.1 OOCSS (CSS orientado a objetos): este es un método de diseño de CSS orientado a objetos, que trata los módulos de la interfaz de usuario como objetos independientes y descompone los estilos en dos partes, estructura y aspecto. Los estilos estructurales generalmente se definen en nombres de clase, mientras que los estilos de máscara se definen en nombres de clase con sufijo, por ejemplo: .button, .button-red.
6.2 SMACSS (Arquitectura escalable y modular para CSS): esta es una arquitectura CSS escalable y modular que descompone las hojas de estilo en cinco niveles: base, diseño, módulo, estado y tema. Cada nivel tiene una convención de nomenclatura y una organización correspondientes.
6.3 ACSS (Atomic CSS): este es un método de diseño de CSS basado en clases atómicas, que define los estilos como un único par de atributo y valor, y cada par de atributo y valor corresponde a una clase atómica. Este enfoque puede reducir en gran medida la duplicación y la redundancia de estilos y mejorar la capacidad de mantenimiento de las hojas de estilo.
6.4, Módulos CSS: este es un método de modularización y componentes de CSS, que trata las hojas de estilo como módulos independientes, cada uno con su propio espacio de nombres y alcance local, para evitar conflictos de estilo y mejorar los componentes de reutilización.
Las diferentes convenciones de nomenclatura son adecuadas para diferentes proyectos y equipos. Elegir una convención de nomenclatura que se adapte a usted puede mejorar la capacidad de mantenimiento y la reutilización del código CSS.
7. Sugerencias sobre la semántica de nombres de JavaScript
En JavaScript, la semántica de nombres generalmente se refiere al método de codificación de nombres de variables, nombres de funciones, nombres de clases y otros nombres simbólicos que son claros, fáciles de entender y expresan significado y propósito. Aquí hay algunas sugerencias para nombrar la semántica:
7.1 Nombre de la variable: el nombre de la variable debe describir con precisión el contenido almacenado en la variable, y se deben evitar abreviaturas o abreviaturas a menos que la abreviatura o abreviatura sea ampliamente aceptada. Por ejemplo, el uso de "fruta" para fruta y "precio" para precio no debe usarse usrNm para representar un nombre de usuario, sino que debe usarse userName.
7.2. Nombre de la función: el nombre de la función debe describir con precisión el propósito y la función de la función. La nomenclatura de mayúsculas y minúsculas que comienza con una letra minúscula y la forma de verbo más sustantivo son más fáciles de entender. Por ejemplo, use `calculateTotal` para calcular la cantidad total, use `displayMessage` para mostrar mensajes, getUserNameobtener nombres de usuario, validateEmailverificar direcciones de correo electrónico, etc.
7.3 Nombre de la clase: El nombre de la clase debe describir con precisión el propósito y la función de la clase. Por ejemplo, utilice `Person` para representar a un ser humano, `Car` para representar un vehículo, etc.
7.4 Nombre de la constante: El nombre de la constante debe estar compuesto por letras mayúsculas y guiones bajos, y describir el propósito y el significado de la constante. Por ejemplo, use `MAX_WIDTH` para el ancho máximo, `PI` para pi, etc.
7.5 Valor de enumeración: El valor de enumeración debe estar compuesto por letras mayúsculas y guiones bajos, y describir el propósito y el significado del valor de enumeración. Por ejemplo, use `COLOR_RED` para rojo, `SIZE_LARGE` para grande, etc.
7.6 Valor booleano: Si una variable tiene solo dos valores, es decir, verdadero y falso, debe nombrarse con un adjetivo o el participio pasado del verbo. Por ejemplo, use `isVisible` para indicar si está visible, use `isDone` para indicar si está hecho, etc.
7.7 Nombre de la función de devolución de llamada: el nombre de la función de devolución de llamada debe describir con precisión la función y el propósito de la función de devolución de llamada. Por ejemplo, use `onSuccess` para indicar la función de devolución de llamada que se ejecuta cuando la operación es exitosa, use `onError` para indicar la función de devolución de llamada que se ejecuta cuando la operación falla, etc.
7.8 El nombre de la clase debe utilizar el método de denominación de mayúsculas y minúsculas comenzando con una letra mayúscula, que puede describir el significado representado por la clase. Por ejemplo, una clase que representa a un usuario debe tener el nombre Usery una clase que representa un elemento debe tener el nombre Product.
Al nombrar la semántica, el código puede ser más fácil de entender y mantener, y se puede mejorar la legibilidad y la capacidad de mantenimiento del código.
Ocho, js guarda el valor del atributo del objeto como una variable local
const person = {
name: 'John',
age: 30,
gender: 'male'
};
//推荐
const { name, age, gender } = person;
console.log(name, age, gender);
//不推荐
console.log(person.name, person.age, person.gender);Nueve, el criterio de función mínima
El Principio de Función Mínima (Single Responsibility Principle, SRP) significa que al escribir una función, se debe garantizar que la responsabilidad de la función sea única, es decir, cada función solo debe hacer una cosa. Esto hace que las funciones sean más limpias, más legibles y más fáciles de mantener y probar. SRP es uno de los principios fundamentales de la programación orientada a objetos.
Seguir el SRP puede tener los siguientes beneficios:
1. Mejorar la legibilidad y mantenibilidad del código: cada función es responsable de una sola responsabilidad, la lógica del código es más clara y es fácil de entender y modificar.
2. Mejorar la capacidad de prueba del código: cada función tiene solo una responsabilidad, y se pueden escribir casos de prueba más precisos para hacer que el código sea más robusto y estable.
3. Mejorar la reutilización del código: Las funciones con una sola responsabilidad se pueden reutilizar en diferentes escenarios, evitando funciones redundantes y la duplicación de código.
4. Mejor modularización y encapsulación: las funciones con responsabilidades similares se pueden combinar en un módulo o clase para mejorar la reutilización y el mantenimiento del código.
En la programación real, hay muchas formas de seguir SRP, como:
1. Cada función maneja solo un parámetro, no múltiples parámetros.
2. Cada función devuelve solo un valor o modifica solo un valor.
3. Dividir una función en múltiples funciones, y cada función solo es responsable de una responsabilidad específica.
4. Divida una función en varios pasos, cada paso responsable de una sola responsabilidad, y luego combine estos pasos en una función.
10. Se recomienda utilizar programación funcional
Aquí hay un ejemplo simple de programación funcional de JavaScript que toma otra función como argumento, aplica esa función a cada elemento de la matriz y devuelve la matriz resultante:
function mapArray(array, f) {
var result = [];
for (var i = 0; i < array.length; i++) {
result.push(f(array[i]));
}
return result;
}
// 定义一个函数，计算一个数的平方
function square(x) {
return x * x;
}
var numbers = [1, 2, 3, 4, 5];
// 使用函数式编程，将 square 函数应用到 numbers 数组的每个元素中
var squares = mapArray(numbers, square);
console.log(squares); // [1, 4, 9, 16, 25]
En este ejemplo, definimos una función mapArray()que toma una matriz y una función como argumentos, aplica la función a cada elemento de la matriz, almacena el resultado en una nueva matriz y devuelve la nueva matriz. También definimos una función square()que calcula el cuadrado de un número. Luego almacenamos el cuadrado de cada elemento en la matriz en una matriz usando mapArray() function y square() function y enviamos la matriz a la consola usando function .numberssquaresconsole.log()squares
11. Especificación de desarrollo del proyecto Vue
11.1, estilo de código
Use eslint en el proyecto Vue para garantizar un estilo de código unificado. Para configuraciones específicas, consulte el documento oficial eslint-config-vue
11.2 Estructura del directorio
La estructura de directorios de un proyecto Vue debe ser clara para facilitar la organización y el mantenimiento del código.
11.2.1 Estructura básica de directorios
|-- dist // 打包后的文件目录
|-- public // 公共静态资源文件，如index.html
| |-- index.html
|-- src // 源码目录
| |-- api // 接口请求相关文件
| | |-- index.js // 请求封装入口文件
| | |-- api.js // 接口具体实现文件
| | |-- ... // 其他接口实现文件
| |-- assets // 图片，字体等静态资源文件
| |-- components // 公共组件目录
| |-- mixins // 公共 mixins
| |-- router // 路由文件
| |-- store // Vuex 状态管理文件
| |-- utils // 公共工具函数
| |-- views // 页面组件目录
| |-- App.vue // 根组件
| |-- main.js // 入口文件
|-- .gitignore // git 忽略文件
|-- babel.config.js // babel 配置文件
|-- package.json // 依赖配置文件
|-- README.md // 项目说明文件
|-- vue.config.js // Vue 配置文件
11.2.2 Estructura del directorio de componentes
|-- components
| |-- Login
| | |-- index.js // 组件入口文件
| | |-- Login.vue // 组件代码文件
| | |-- Login.scss // 组件样式文件
| | |-- Login.spec.js // 组件测试文件
| | |-- Login.story.js // 组件故事文件
11.3 Denominación de componentes
El nombre de los componentes de Vue debe ser significativo para que otros puedan entender y usar el código.
Reglas de nomenclatura:
- todas las palabras en minúsculas
- Utilice un guión (-) entre varias palabras
- Se recomienda utilizar el mismo prefijo para componentes con funciones similares, como
v-button,v-button-group
Evite las abreviaturas en los nombres de los componentes de vue, por ejemplo, utilice buttonen lugar de btn.
11.4 Estructura de componentes
La estructura de los componentes de Vue debe ser clara, fácil de reutilizar y mantener.
La estructura de código del componente vue se sugiere de la siguiente manera:
<template>
<div class="container">
<!-- 组件主体内容 -->
</div>
</template>
<script>
export default {
name: 'ComponentName', // vue 组件名称
props: { // vue 组件属性
propA: {
type: String,
default: 'A'
},
propB: {
type: Number,
default: 0
}
},
data () {
return {} // vue 组件数据
},
computed: { // vue 计算属性
computedA () {
// ...
}
},
watch: { // vue 监听器
'watchA' (val, oldVal) {
// ...
}
},
methods: { // vue 组件方法
methodA () {
// ...
}
},
// vue 生命周期
beforeCreate () {},
created () {},
beforeMount () {},
mounted () {},
beforeUpdate () {},
updated () {},
beforeDestroy () {},
destroyed () {}
}
</script>
<style lang="scss" scoped>
.container {
/* 样式代码 */
}
</style>
11.5, comentarios de código
Los comentarios del código son muy importantes para la mantenibilidad y la legibilidad. Se recomienda hacer comentarios en el código para facilitar que otros comprendan y modifiquen el código.
Reglas de anotación:
- Se dejan líneas en blanco entre los comentarios para distinguir las diferentes secciones.
- El contenido del comentario debe ser conciso y claro, y no debe ser demasiado largo.
- Coloque el contenido del comentario sobre el código comentado en lugar de a la derecha
- Si puede entenderlo a través de la nomenclatura estándar, no necesita escribir comentarios
11.6 Otros
- Los estilos de componentes se escriben uniformemente usando SCSS
- Está prohibido usar
v-ifyv-forusar en combinación, porque esto afectará el rendimiento, se recomienda usar el método de cálculo de propiedades. - Los nombres de variables, nombres de funciones, nombres de archivos, etc. deben nombrarse de manera significativa y no utilizar métodos de nomenclatura de un solo carácter, como
a,b - Al usar la administración de estado de Vuex, se recomienda que un solo archivo no supere las 400 líneas de código
12. Este artículo se creó con la ayuda de AI, bienvenido a intercambiar y corregirme, seguirme y aprender juntos
Link de referencia
Lista de verificación de CheckList de revisión de código del equipo front-end - Nuggets