Pensamientos después de leer "La forma de limpiar el código"

Prefacio

Muchas veces, vemos un código antiguo y pensamos que es increíble. ¿Cómo puede haber un código tan malo? Pensarás quién escribió un código tan desordenado (a veces te sorprenderá encontrarte a ti mismo), y entonces solo puedes Simplemente muerda la viñeta y lea lo que significan estos códigos, y luego modifique cuidadosamente uno de ellos para permitir que su trabajo se complete, luego envíelo.

De esta manera, el código se descompone lentamente en cada envío y, finalmente, se vuelve apestoso, y luego puede incluso causar algunas vulnerabilidades y crisis potenciales (he oído que algunas empresas fallan porque el código del proyecto es realmente inmaterial. Arriba).

Por lo tanto, el cuidado del código es demasiado importante, mucha gente piensa que es suficiente para que el código "funcione" y luego comience la siguiente tarea. De hecho, escribir código es muy similar a escribir artículos, informes, etc. Al principio, escribe lo que quiere expresar y luego lo considera y delibera lentamente hasta lograr lo que quiere.

Introducción

El libro "Código limpio", desde la secuencia de código más simple, la optimización de nombres de variables, hasta el modo, la optimización del sistema y otros aspectos, presenta algunas sugerencias y soluciones, para que el código se vea más conciso y fácil de leer. En el último capítulo, el autor enumera por completo su experiencia de optimización y ordenación del código en el proceso de trabajo, lo que puede considerarse como el resumen general de este libro. Si no desea leer el capítulo anterior, puede obtener información directamente en el Capítulo 17. Punto, simplemente no es muy detallado. Además, los dos primeros capítulos son para obtener el proceso de optimización práctica paso a paso del código del proyecto completo y descomponer todo el proceso de pensamiento del autor. En realidad, es bastante interesante seguirlo, y puedo comprender mejor algunas de las cosas que el autor dijo en los capítulos anteriores.

Optimización de código

A continuación, repasemos algunos puntos que creo que son más inspiradores y me hacen sentir mejor.

nombre

El primero es nombrar. Un buen nombre es muy importante. Piensa en por qué cuando elegimos nuestro propio nombre, nuestros padres quieren rompernos la cabeza o gastar dinero para darnos un nombre agradable, agradable y reconocible. Del mismo modo, nuestros nombres de variables y de métodos , Nombre de la clase, nombre del archivo, etc., asegúrese de pasar más tiempo pensando en cómo obtenerlo, es mejor poder ver lo que esto significa de un vistazo.

private BroadcastReceiver mBroadcastReceiver;
private PublicNotifyReceiver mReceiver

Como estos dos, al mirar el código, ¿eh? Qué tipo de transmisión es esta, y luego solo puede mirar el lugar definido para ver qué transmisiones se ha registrado para recibir, y el nombre de estas dos variables en realidad no tiene sentido, y no hay ninguna indicación de lo que está haciendo. ¡utilizar! Si lo reemplazó appSettingChangeBroadcastReceivery dialogPushBroadcastReceiverluego? Entonces, ¿podemos simplemente mirar el nombre y saber que el primero es la transmisión de "cambios en la configuración de la aplicación", y el segundo es la transmisión de "monitoreo push emergente"? Elija un buen nombre para evitar la confusión al leer el código, ¿por qué no hacerlo? Entonces, deje que el nombre tenga un significado preciso .
Veamos un nombre de nuevo getHour(Calendar calendar). Este es un método en una clase de herramientas, pero no puedo ver para qué sirve. Al principio pensé que era para obtener el campo de hora de este calendario, y pensé en obtener la hora actual. De hecho, , Ha obtenido HH:mmtal cadena de tiempo formateada. Entonces, su nombre no es el mismo que lo que hace. Por un lado, tenemos que hacer clic para saber qué se hace adentro. Por otro lado, incluso si existe dicha función, cuando habitualmente queremos usar un El método de esta función, como resultado, del nombre del método, no existe tal método, y luego escribí uno nuevo. ¿No es un duplicado? por lo tanto, haga que el nombre sea significativo y que sean iguales, el nombre y lo que hacen son consistentes .

Comentario

En el proceso de escribir código, escribiremos muchos comentarios, y hay muchas cosas a las que prestar atención al escribir comentarios, no solo casualmente.

• Comenta solo cuando sea necesario

No es necesario escribir comentarios en todas partes, solo necesitamos indicar por qué los escribimos en algunos lugares que son más complicados o tienen funciones especiales.

• No escribas tonterías

    /**
     * 日期格式 -- yyyy年
     */
    public static final String DATE_FORMAT_Y = "yyyy年";
    /**
     * 日期格式 -- yyyy年MM月
     */
    public static final String DATE_FORMAT_Y_M = "yyyy年MM月";

Por ejemplo, sabemos de un vistazo qué es ¿Por qué desperdiciamos tantas líneas para escribir comentarios? Con esta energía, podemos pensar mejor en nombrar. Muchas variables y métodos se pueden nombrar directamente para decirle a los lectores lo que están haciendo. No hay necesidad de escribir comentarios sobre todo .

• Formato de nota

/**
 * <b>Project</b> <i>almanac</i><br>
 * <b>Create Date</b> <i>2014/10/18</i><br>
 * <b>Author</b> <i>***</i><br>
 * <b>Email</b> <i>***@mmclick.com</i><br>
 * <b>Update Date</b> <i>2014/10/18 14:49</i><br>
 * <b>Last Update</b> <i>***</i><br>
 * <b>Description</b> <i>
 * <p/>与时间有关的工具类
 * </i>
 */
public class TimeUtils {
...
}

Mira este comentario sobre el nombre de la clase, ¡realmente parece particularmente incómodo! Primero, mezcle comentarios en lenguaje html en el código java. Tal vez diría que estará muy estandarizado al exportar doc, pero de hecho, doc no se exporta mucho y, la mayoría de las veces, todavía usamos ide o editor de texto. Para leer este código, y luego las diversas etiquetas se mezclan, causando grandes inconvenientes para la lectura, este formato es simplemente un dolor de cabeza.
En segundo lugar, todos los comentarios son cosas inútiles. La herramienta de administración de versiones actual puede registrar mucha información para nosotros, incluido el creador de la clase, el tiempo de creación y el tiempo de actualización, lo cual es completamente innecesario en los comentarios.
En tercer lugar, la descripción es redundante. Generalmente vemos aquellos que terminan con Utils y sabemos que esto indica que es una clase de herramienta, TimeUtils, es decir, una clase de herramienta relacionada con el tiempo Entonces, ¿cuál es el rol de la descripción anterior?

No escriba código repetitivo

No escribas código repetitivo, no escribas código repetitivo, no escribas código repetitivo, extrae y encapsula algunos códigos que se usan en múltiples lugares, esto no es mucho que decir, es muy simple y muy importante.

función

La primera es la cantidad de código de función . Normalmente, la función que se muestra en una pantalla de nuestro editor es generalmente de 30 a 40 líneas. Debemos controlar la función para que termine dentro de una pantalla para que la función sea corta y concisa.
Responsabilidad única . Debemos hacer todo lo posible para permitir que una función haga solo una cosa y no permitir que se mezclen demasiadas funciones en una función. Si hace muchas cosas, debe nombrar la función correctamente. No puede nombrar la función completa después de una de las funciones.
No tenga demasiados parámetros . El número más ideal de parámetros es cero, seguido de uno, luego dos y tres deben evitarse tanto como sea posible. Hay suficientes razones especiales para utilizar más de tres parámetros.
Orden de funciones . Cuando leemos el código, a menudo es de arriba a abajo, por lo que cuando escribimos funciones, también debemos prestar atención a la función que aparece primero, y se llaman otras funciones en la función, luego síguela, mire el código así No hay necesidad de saltar, quién soy, dónde estoy, dónde quiero volver ...
Por ejemplo, un método onCreate en mi Actividad, primero puede ver lo que se hace en él de un vistazo y luego seguir el orden de ejecución paso a paso. Mirando hacia abajo un paso, no hay necesidad de saltar a ninguna parte en todo el proceso, y puede saber cómo es mi flujo de procesamiento después de ingresar a la página.

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.alc_activity_home_layout);
        linghitSecurityCheck();
        initView();
        initWork();
        addDialogs();
        initAfterUiShow();
        handleDelayTask();
    }

Secuencia de funciones (presione Ctrl + F12 para que aparezca)

diseño

El diseño de toda la estructura del código no dice cuán complicado debe ser el diseño, la clave es que sea fácil de usar y de leer. Pero esto también se basa en la acumulación de experiencia y puedes escribir más lentamente. Observe más algunas de las mejores estructuras escritas por otros, cópielas primero y luego cámbielas lentamente para convertirlas gradualmente en lo que desea.

Escribir al final

Me gusta especialmente la cita al principio del libro: "¡Haz que el campamento esté más limpio que cuando viniste!"

Si cada vez que se registra, el código es más limpio que cuando se retira, entonces el código no estará dañado. No necesariamente requiere mucho esfuerzo limpiar, tal vez solo cambiar el nombre de una variable, dividir una función que sea demasiado larga, eliminar un poco de código duplicado y limpiar una instrucción if anidada.

Cada miembro, cada vez que se mueve el código, puede hacer esto, para que el código no se pudra.

Por último, les recomiendo a todos que lean el libro "Limpieza de códigos" ~