[Java] Manual de desarrollo de Ali Java - Resumen parcial (1)

¡Acostúmbrate a escribir juntos! Este es el segundo día de mi participación en el "Nuggets Daily New Plan · April Update Challenge", haz clic para ver los detalles del evento .

Este es mi propio resumen de algunas regulaciones del Manual de desarrollo de Ali Java (Edición Huangshan). Hay muchos puntos de conocimiento en el manual que a menudo se encuentran y se confunden en el desarrollo diario. Escriba esta publicación de blog para su revisión diaria y pruébela gradualmente en el trabajo y el desarrollo diario.

El acceso a la documentación se puede descargar a través del enlace de GitHub .

El estilo de denominación

1.1 Todos los nombres

  • Todos los nombres relacionados con la programación no deben_$ comenzar ni terminar con un guión bajo o un signo de dólar ;
  • Todos los nombres relacionados con la programación están estrictamente prohibidos para usar la combinación de Pinyin e inglés, y no está permitido usar chino directamente (de acuerdo con la ortografía y la gramática correctas en inglés);
  • Evite palabras raciales o abusivas en cualquier idioma humano en el código y en los comentarios ;
  • Para lograr el objetivo de la autoexplicación del código, cualquier elemento de programación personalizado se nombra con una combinación completa de palabras para expresar;
  • Si los módulos, las interfaces, las clases y los métodos usan patrones de diseño, deben reflejar los patrones específicos al nombrarlos.

1.2, clase, interfaz

  • El nombre de la clase usa el estilo UpperCamelCase (comenzando con letras mayúsculas en inglés ) ;

  • Los nombres de clases abstractas comienzan con Abstract o Base ;

  • Los nombres de clase de excepción terminan con Exception ;

  • El nombre de la clase de prueba comienza con el nombre de la clase que se va a probar y termina con Test ;

  • No agregue ningún modificador a los métodos y propiedades en la clase de interfaz (no agregue público), mantenga el código conciso y agregue comentarios válidos de Javadoc*;

  • 接口和实现类的命名规则:

    1. 对于Service和DAO类,内部的实现类用Impl的后缀与接口区别;

      CacheServiceImpl实现CacheService接口

    2. 如果是形容能力的接口名称,取对应的形容词为接口名(通常是-able结尾的形容词)。

      AbstractTranslator实现Translatable

  • 枚举类*名带上Enum后缀,枚举成员名称需要全大写,单词间下划线隔开。

1.3、方法、参数、成员变量、局部变量、常量、数组

  • 方法名、参数名、成员变量、局部变量使用lowerCamelCase风格(使用小写英文字母打头);
  • 常量命名应该全部大写,单词间用下划线隔开;
  • 类型与中括号紧挨相连来定义数组 Type[] arrayList
  • 在常量与变量命名时,表示类型的名词放在词尾,以提高辨识度nameList/startTime/workQueue

1.4、包名

  • 包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。

1.5、各层命名规约

  • Service/DAO层方法命名规约:

    1. 获取单个对象的方法:get为前缀
    2. 获取多个对象的方法:list为前缀,复数结尾,如listObjects
    3. 获取统计值的方法:count为前缀
    4. 插入的方法:save/insert做前缀
    5. 删除的方法:remove/delete做前缀
    6. 修改的方法:update做前缀
  • 领域模型命名规约

    1. 数据对象:xxxDO,xxx为数据表名
    2. 数据传输对象:xxxDTO,xxx为业务领域相关的名称
    3. 展示对象:xxxVO,xxx一般为网页名称
    4. POJO是DO/DTO*/BO*/VO*的统称,禁止命名成xxxPOJO

二、代码格式

2.1、大括号、小括号

  • 如果大括号内为空,简洁地写成{}即可,大括号中间无需换行和空格;

  • 如果非空代码块,则:

    public static void main(String[] args) {// 左边大括号前加空格切不换行,左大括号后换行
    			if (xxx == xx) {
    					xxxxx
    					// 右大括号前换行,右大括号后有else,else在同一行,不用换行
    			} else {
    					xxxxx
    			} // 在右大括号后直接结束,则必须换行
    }
    复制代码
  • if/for/while/switch/do等保留字与左右括号之间都必须加空格;

  • 左小括号和右边相邻字符之间不需要空格;

  • 右小括号和左边相邻字符之间不需要空格;

  • 左大括号前要加空格;

2.2、运算符

  • Se debe agregar un espacio a los lados izquierdo y derecho de cualquier operador binario o ternario (incluido el operador de asignación =, el operador lógico &&, los símbolos de suma, resta, multiplicación y división, etc.;

2.3 Otros

  • Use 4 espacios para la sangría, prohíba el uso de caracteres de tabulación (puede configurar la sangría de tabulación en IDE);

  • Hay un único espacio entre la doble barra del comentario y el contenido del comentario;

  • Al realizar una conversión de tipo, no se requiere espacio entre el paréntesis de cierre y el valor de conversión;

  • El número de caracteres en una sola línea está limitado a no más de 120. Si excede, se requiere una nueva línea. Siga los siguientes principios al envolver una línea:

    • La segunda línea tiene una sangría de 4 espacios en relación con la primera línea, a partir de la tercera línea y ya no tiene sangría;
    • El operador se ajusta con lo siguiente;
    • La notación de punto de una llamada de método se ajusta con el siguiente texto;
    • Cuando es necesario envolver varios parámetros en una llamada de método, se realizan después de la coma;
    • No envuelva una línea antes de los paréntesis.
  • Cuando se definen y pasan parámetros de método, se debe agregar un espacio después de las comas de varios parámetros;

    method(arg1, arg2, arg3);

  • El número total de líneas para un solo método no excede las 80 líneas;

  • No es necesario agregar varios espacios para alinear el signo igual de la variable asignada con el signo igual en la posición correspondiente en la línea anterior;


Continuará....

3. Resumen

En el futuro, agregaré protocolos relacionados con MySQL y Java uno tras otro cuando tenga tiempo.Muchos protocolos son un desastre cuando no están documentados. Por ejemplo, después de leer el manual de desarrollo de Ali, descubrí que muchas partes del marco de trabajo de la empresa siguen este protocolo, pero no hay ningún documento al que referirse. La mayoría de los estilos de codificación están determinados por el "tipo grande" que organiza o construye el marco el comienzo del proyecto El tono principal, algunas personas de seguimiento siguen el desarrollo y algunas tienen su propio estilo, lo que hace que muchas cosas en el proyecto sean difíciles de entender y comprender, y de vez en cuando ocurren problemas de redundancia y eficiencia.

Recientemente, estaba escuchando el programa de podcast "Evolución organizacional". Hay mucho conocimiento duro y productos secos. La promoción de Feishu, el padre de la transmisión dura, también es muy fuerte, lo que me hace sentir que no es un buena compañía sin usar Feishu. Pero hay una cosa con la que estoy de acuerdo, no importa el período de trabajo que sea, es necesario dejar documentos en el trabajo, ya sea para que los demás sepan lo que has hecho, o lo que harás, o las personas detrás de ti. después de que te vayas Cómo tomar el control de tu trabajo es una buena referencia y un gran recurso para tu propia revisión. Se recomienda que deje documentos activamente, pero no se limita al formulario.

Supongo que te gusta

Origin juejin.im/post/7084972383508889636
Recomendado
Clasificación