Primeros pasos aprendiendo "El camino hacia la limpieza del código"

Esta publicación de blog lo resume muy bien:

"El camino del código limpio" Lectura compartida_El camino del código limpio Lectura en línea_Alpinist Wang's Blog-CSDN Blog

código limpio

1. ¿Qué es el código simple?

   • pasar todas las pruebas
   • sin código duplicado
   • Reflejar todos los conceptos de diseño en el sistema.
   • Incluya la menor cantidad posible de entidades, como clases, métodos, funciones, etc.

2. Haz que el código sea más limpio que cuando viniste. No tiene que requerir mucho esfuerzo, incluso si solo se trata de cambiar el nombre de una variable, dividir una función que es demasiado larga, eliminar un poco de código repetitivo, limpiar una instrucción if anidada,

denominación significativa

1. No use palabras sin sentido en variables, como: información, datos, variedades

2. Use nombres legibles, como: use generationTimestamp en lugar de genymdhms para facilitar la comunicación

3. Use nombres que se puedan buscar, como: int WORK_DAYS_PER_WEEK = 5;solo deje el nombre que refleje la intención del autor en el código

4. Más bien codifique ShapeFactoryImpl para la clase de implementación que IShapeFactory para la interfaz. Ambos son útiles en el sistema de gestión de Zoyi.

función

1. Cuanto más corto, mejor. No debe haber un segundo nivel de sangría en el cuerpo de la función, ¡y todos los métodos llamados están encapsulados!
2. Cada función tiene un solo nivel de abstracción.
3. Para las diversas situaciones de la declaración de cambio, se introduce una fábrica abstracta y el cambio solo crea objetos polimórficos.
4. Extraiga la parte principal del bloque de código try/catch y forme una función
5. Escribir código es muy parecido a escribir cualquier otra cosa. Al escribir una disertación o un artículo, escriba primero lo que se le ocurra y luego pulíelo más tarde. El primer borrador puede ser tosco y desordenado, pero después de repetidas deliberaciones y escrutinios, hasta que alcanza la forma en mente. No escriba funciones de acuerdo con las reglas desde el principio, nadie debería poder hacerlo.

nota

1. Los comentarios siempre son un fracaso. Nunca podemos encontrar una manera de expresarnos sin anotaciones, por lo que siempre habrá anotaciones, lo cual no es algo para celebrar. Por lo tanto, aunque a veces se requieren anotaciones, debemos prestar más atención a reducir la cantidad de anotaciones tanto como sea posible.

2. ¿Qué es un buen comentario?

   • información legal
   • Comentarios informativos: explicar el valor de retorno de un método abstracto
   • Anotación que proporciona intención
   • Explique: explique el código que no puede modificar
   • advertencia

3. ¿Qué son los malos comentarios?

   • Comentarios redundantes: si el código ya refleja, no escribas tonterías
   • Comentarios conformes: JavaDoc para cada función y variable es realmente complicado
   • Código comentado: ¡elimínelo directamente!

Formato

1. Cada función ocupa un pequeño espacio en la dirección vertical, y los bloques de código no relacionados están separados por líneas en blanco.
2. lo más corto posible horizontalmente

Objetos y estructuras de datos

1. El código de procedimiento (código que utiliza estructuras de datos) facilita la adición de nuevas funciones sin cambiar las estructuras de datos existentes; el código orientado a objetos facilita la adición de nuevas clases sin cambiar las funciones existentes.
2. Ley de Deméter: Los métodos no deben llamar a métodos de objetos devueltos por ninguna función. En otras palabras, solo hable con amigos, no con extraños.

manejo de errores

A partir de este capítulo, no puedo entenderlo un poco. Debido a que el código se escribe menos, es difícil que resuene.

Por lo tanto, es mejor practicar escribiendo código primero, y luego aprender después de tener un poco de reserva...