El estándar de codificación explicado por los grandes del grupo , el propósito fundamental del estándar de codificación es no solo aclarar el código de un vistazo, sino también facilitar la comprensión del propósito y el significado del programa de código escrito por el desarrollador. . Como resultado, se utiliza para reducir la dificultad y la ambigüedad en la comprensión de la función real del código debido a la sustitución del personal de desarrollo y mantenimiento o la memoria borrosa o la confusión causada por la falta de mantenimiento a largo plazo en el proyecto. Además, también se mejoran la eficiencia y la eficacia de la revisión del código .
Un buen código no es una montaña de mierda, es algo que todos pueden entender y reescribir
Soluciones industriales:
-
ladrillos de datos: https://github.com/databricks/scala-style-guide/blob/master/README-ZH.md
-
google: https://github.com/zh-google-styleguide/zh-google-styleguide
Código que es fácil de mantener o comprensible para otros, que consta de al menos tres partes
- Convenciones de nombres
- estilo de visualización de código
- comentario de código
1. Convención de nomenclatura
en principio
- La denominación se ajusta a las características de la lengua.
- La denominación refleja las características de los elementos del código.
- La denominación se lee mejor del texto.
métodos específicos
- No comience y termine con un guión bajo o un signo de dólar: debe comenzar con una letra, terminar con una letra y un número
- Está estrictamente prohibido mezclar pinyin e inglés, y mucho menos chino.
- Denominación de Camel-Case: las clases usan joroba grande, las variables y los métodos usan joroba pequeña
- El nombre de la constante debe escribirse en mayúscula y las palabras deben estar separadas por guiones bajos, para garantizar una semántica completa y no ser demasiado larga.
- Las clases abstractas deben comenzar con Abstract o Base, las clases de excepción deben terminar con Exception y las clases de prueba deben terminar con Test
- Boolean en la clase POJO no puede tener el prefijo is
- Los nombres de los paquetes están uniformemente en minúsculas y solo se pueden usar en números singulares. Los nombres de los paquetes deben seguir la convención de nomenclatura de los nombres de paquetes en Java, es decir, usar todas las letras ASCII en minúsculas.
- Ponga fin a las abreviaturas no estándar: condition -> con ?connection?
- Cuando se nombran constantes o variables, la palabra que indica el tipo se coloca al final para aumentar el reconocimiento: xxxList, xxxMap
- Los módulos, las interfaces, las clases y los métodos parecen utilizar patrones de diseño, y deberían aparecer patrones de diseño específicos al nombrarlos.
- La clase de enumeración tiene el sufijo enum, los miembros están en mayúsculas y las palabras están separadas por guiones bajos.
- No se permite el uso directo de valores mágicos (es decir, constantes no predefinidas) en el código
2. Estilo de visualización del código:
en principio:
- Expresar la jerarquía y regularidad del código.
- Comprensión intuitiva, rápida y precisa de la lógica empresarial
métodos específicos
- sangría con espacios? ¿pestaña? 2, 4, 8 espacios, se recomiendan dos espacios
- Se deben agregar espacios a los lados izquierdo y derecho de los operadores binarios y ternarios: val i = 1 + 1
- Solo hay un espacio entre las barras dobles del comentario y el contenido del comentario // Texto del comentario
- No debe haber espacios entre los paréntesis izquierdo y derecho y los caracteres adyacentes dentro de los corchetes: (aa, bb)
- Debe haber un espacio antes de la llave de apertura.
- Deja un espacio después de la coma. Seq("a", "b", "c") // usar de esta manera
- Deje un espacio después de los dos puntos.
- operador se ajusta con lo siguiente
- La notación de puntos para las llamadas a métodos se ajusta con lo siguiente
- Cuando es necesario envolver varios parámetros de una llamada de método, envuélvalos después de la coma
- No rompa la línea antes de los paréntesis
- Sentencias de control: Deben usarse llaves en if, else, for, while, do-while, etc., incluso si hay una línea de código
- Las operaciones de asignación no están permitidas en las expresiones condicionales y las combinaciones lógicas complejas (3 o más) no están permitidas en las expresiones de juicio.
3. Comentarios sobre el código:
en principio
- escribir tantos comentarios como sea posible
- Menos comentarios, un buen código puede comprender el contenido del método de acuerdo con la convención de nomenclatura y la nomenclatura
- Modificar el código y también modificar los comentarios.
estilo:
- Comentarios de la documentación
- Comentarios de texto: los comentarios son "sugerencias" para el código, no documentación
- Las anotaciones de clase deben tener,
- Los comentarios de variables se comentan después
- Las clases y los métodos están anotados arriba.
- añadir una plantilla de clase
Acerca de los cierres
- Evite usar retorno en cierres
- se convertirá en una declaración
scala.runtime.NonLocalReturnControlde excepcióntry/catch, lo que puede conducir a un comportamiento inesperado - Los cierres no son adecuados para proyectos complejos a gran escala
- Abstraer y mejorar algunas clases de herramientas.
otro
- Evite las listas de varios argumentos
- case class Persona(nombre: Cadena, edad: Int)(secreto: Cadena)
- Implícito tiene reglas de análisis muy complicadas, lo que puede hacer que el código sea extremadamente difícil de entender.
- No use símbolos como nombres de métodos
- canal! mensaje
- corriente1 >>= corriente2
Normas Generales Obligatorias:
- No comience y termine con un guión bajo o un signo de dólar: debe comenzar con una letra, terminar con una letra y un número
- Está estrictamente prohibido mezclar pinyin e inglés, y mucho menos chino.
- Denominación de Camel-Case: las clases usan joroba grande, las variables y los métodos usan joroba pequeña
- El nombre de la constante debe escribirse en mayúscula y las palabras deben estar separadas por guiones bajos, para garantizar una semántica completa y no ser demasiado larga.
- Las clases abstractas deben comenzar con Abstract o Base, las clases de excepción deben terminar con Exception y las clases de prueba deben terminar con Test
- Boolean en la clase POJO no puede tener el prefijo is
- Los nombres de los paquetes están uniformemente en minúsculas y solo se pueden usar en números singulares. Los nombres de los paquetes deben seguir la convención de nomenclatura de los nombres de paquetes en Java, es decir, usar todas las letras ASCII en minúsculas.
- Se deben agregar espacios a los lados izquierdo y derecho de los operadores binarios y ternarios: val i = 1 + 1
- No debe haber espacios entre los paréntesis izquierdo y derecho y los caracteres adyacentes dentro de los corchetes: (aa, bb)
- Debe haber un espacio antes de la llave de apertura.
- Deja un espacio después de la coma. Seq("a", "b", "c") // usar de esta manera
- Deje un espacio después de los dos puntos.
- Se utiliza para dividir fragmentos de código con funciones similares, cohesión lógica y significado similar para hacer que el diseño del código sea más claro e intentar unir los bloques de código relacionados.
- operador se ajusta con lo siguiente
- La notación de puntos para las llamadas a métodos se ajusta con lo siguiente
- Cuando es necesario envolver varios parámetros de una llamada de método, envuélvalos después de la coma
- No rompa la línea antes de los paréntesis
- Trate de evitar el uso de operadores lógicos negados
- Las declaraciones de métodos deben estar entre paréntesis (incluso sin listas de parámetros)
- Las operaciones de asignación no están permitidas en las expresiones condicionales y las combinaciones lógicas complejas (3 o más) no están permitidas en las expresiones de juicio.
- Los comentarios de variables se comentan después
- Las clases y los métodos están anotados arriba.
¡Gracias por compartir!