Notas de lectura "Artesanía en programación" (1)

prefacio

Recientemente leí el libro "Programming Craftsmanship", escrito por el autor estadounidense Pete Goodliffe, no solo es una guía de estudio, sino también un libro que estimula la pasión por la programación, mostrando una actitud de programación de búsqueda de la excelencia.

En mi opinión, trae no solo mejoras técnicas, mejor dominio de las habilidades de programación, mejora de la eficiencia y calidad del propio desarrollo, sino, lo que es más importante, pensamiento y comprensión de la programación.

Las siguientes son notas de lectura + comprensión personal.El libro está dividido en 24 capítulos, actualmente el capítulo 01-06.

1. Programación defensiva

1.1 Buen código

Hay tres códigos

• Código de trabajo: está bien para la entrada regular, pero puede bloquearse cuando se encuentra con una entrada inesperada
• Código correcto: este código nunca fallará, pero el conjunto de entrada puede ser grande y difícil de probar y, a veces, de entender.
• Buen código: Este tipo de código primero será correcto, y luego será robusto y eficiente.

Creo que el primer capítulo del libro "Java Confusion" es el código para juzgar si un número entero es impar o no. Después de la modificación, cambiará de utilizable a excelente.

// 碰到负整数会有问题
public static boolean isOdd(int i) {
    
    
    return i%2==1;  
}
// 修改后
public static boolean isOdd(int i) {
    
    
    return i%2!=0;  
}

1.2 Técnicas de programación defensiva

Parece fácil escribir un buen código usted mismo, pero es muy difícil escribir un buen código cuando coopera con otros o toma el control del código anterior. En este momento, se necesita usar programación defensiva.

• No haga suposiciones, al igual que el juez anterior si es impar o no, no puede imaginar que el programa solo ingrese números enteros positivos. Una persona puede recordar el código por un corto tiempo, pero después de mucho tiempo o cuando otras personas llaman a su código durante el trabajo en equipo, no lo considerarán.
• Use un buen estilo y diseño de codificación
• No puedo escribir código apresuradamente
• No confiar en nadie
• El objetivo de la codificación es la claridad, no la brevedad. No puede considerar una sola línea de código para resolverlo, sino que debe ser fácil de entender, ya sea usted mismo o los demás.
• Cada uno realiza sus propias funciones.En el desarrollo de Java, las propiedades del bean deben establecerse como privadas, y creo que las responsabilidades de la clase deben coincidir con el nombre y no agregar métodos irrelevantes.
• Encienda todos los interruptores de advertencia en tiempo de compilación, esto es para C/C++
• Usar herramientas de análisis estático
• Usar estructuras de datos seguras
• Comprobar todos los valores devueltos
• Maneje la memoria (u otros valiosos recursos) con cuidado para C/C++
• Las variables se inicializan en la posición de declaración, para C/C++, las declaraciones de Java tienen valores predeterminados
• diferir algunas declaraciones de variables tanto como sea posible
• Usar herramientas de lenguaje estándar para C/C++
• Use una buena herramienta de registro de diagnóstico, Java tiene log4j
• Usa la coerción con precaución
• Proporcione el comportamiento predeterminado, cambie el valor predeterminado y, si no, considere cuidadosamente varias situaciones
• Considere el desbordamiento de números
• Establecer todas las variables que se pueden establecer como constantes a constantes

1.3 Restricciones

C y C ++ restringen el código a través de la aserción de aserción, y Java también puede restringir el código a través de la declaración de aserción

2. Estilo de código

2.1 Para humanos

Escribimos código para tres categorías de lectores:

• Yo mismo: mi letra es fea y me resulta difícil leer, y mucho menos el código.
• Máquina: a la máquina no le importa el estilo, solo necesita compilarse y no informará un error debido al estilo
• Otros: este tipo de persona es la más importante, las habilidades individuales siempre son limitadas y las personas necesitan cooperar para completar las tareas.

Entonces, el estilo del código está orientado al ser humano y a la máquina no le importa. El estilo de un excelente programador es definitivamente diferente al de un novato. El estilo de código escrito por un novato siempre es confuso. Mira el código que escribiste en ese entonces.

2.2 Excelente estilo

Los buenos estilos tienen las siguientes características:

• Consistente: el número de espacios de sangría debe ser consistente, la posición de los corchetes también debe ser consistente, etc.
• Tradicional: use una especificación que sea popular en la industria
• Simplicidad: simple, fácil de aprender para otros, aceptable

El buen estilo no es estático, debe ser aceptado por la mayoría de las personas del equipo.

3. Nombre de código

3.1 Nombrar por qué qué cómo

• Por qué es importante un buen nombre

  Lo que tiene nombre existe, y un buen nombre es fácil de entender y recordar. Las entidades mal nombradas no solo son inconvenientes de administrar, sino que también son engañosas y propensas a errores durante la programación. El nombre de un objeto debe describir claramente el objeto.

• que nombre

  Variables, funciones, clases, espacios de nombres, paquetes, macros, archivos fuente, etc. Estos son los más comunes en programación.

• como nombrar

  vea abajo

3.2 Buena denominación

• Técnicamente correcto, el compilador no reportará un error

• Énfasis en la claridad sobre la brevedad, sin ambigüedad

• De acuerdo con los hábitos del lenguaje, consistente, unificado

• Usando el contexto, si la clase Tree tiene un método countApplesInTree, se puede cambiar a Tree:countApples

3.3 Denominación de variables

• Sustantivos: generalmente representan un objeto físico, y algunas variables que no pueden corresponder a objetos reales también pueden usar sustantivos, como el tiempo transcurrido tiempo_transcurrido

• Verbo: si la variable no se puede representar con un sustantivo, generalmente es un verbo nominalizado, como contar contar

• El nombre de una variable numérica describe la interpretación de su valor, como widget_length

• El nombre de la variable lógica es un nombre de formulario de declaración condicional, como is_red

• Las variables y los tipos deben distinguirse, por lo que la primera letra de una variable generalmente es minúscula, mientras que el tipo es mayúscula

3.4 Denominación de funciones

• Una función es una acción y el nombre contiene al menos un verbo
• Nombrar funciones desde el punto de vista del usuario
• Puede usar guión bajo o camelCase para nombrar

3.5 Denominación de tipos

• Un tipo puede describir algún objeto de datos con estado, en cuyo caso el nombre puede ser un sustantivo

• El tipo también puede ser una clase que implemente una función de devolución de llamada de interfaz, en este caso, el nombre puede ser un verbo

4. Autodocumentación del código

4.1 Por qué eres reacio a escribir documentación

• La mayoría de los programadores tienen un dolor de cabeza por el trabajo de texto y un dolor de cabeza por escribir una gran cantidad de comentarios, y escribir documentos consume mucho tiempo, al igual que leer, por lo que prefieren escribir programas.
• Todos los documentos individuales se actualizan a medida que cambia el código, lo cual es un trabajo horrible en proyectos grandes.
• Una gran cantidad de documentos son difíciles de administrar y deben ser controlados por versión como código
• Los documentos y programas externos son difíciles de vincular y es fácil perderse información importante

4.2 Código autodocumentado

• El código de autodocumentación es hermoso, un código altamente legible que es fácil de entender por sí mismo y no requiere documentación externa.
• Idealmente, el código de autodocumentación no requiere comentarios, lo que afectará la lectura, pero en realidad es difícil de hacer, por lo que se requieren buenos comentarios.

4.3 Consejos

• buen estilo
  • Mantenga la estructura consistente en if/else (por ejemplo, siempre maneje el caso correcto después del if y maneje el caso de error después del else) y manténgalo unificado, y la situación no se puede revertir más adelante.
  • Evite el anidamiento excesivo, use la recursividad con moderación
  • Optimiza cuidadosamente el código
• descompuesto en funciones atómicas
  • Una función que realiza solo una operación, elija un nombre que describa sin ambigüedades la operación, un buen nombre no requiere documentación adicional
  • reducir los efectos secundarios no deseados
  • Sea breve, las funciones pequeñas son fáciles de entender
• Elija el tipo correcto
  • Los valores que nunca necesitan ser modificados se pueden definir como constantes
  • Si el valor descrito por la variable no contiene valores negativos, se debe usar el tipo sin signo (si el idioma lo admite)
  • Use una enumeración para describir un conjunto de valores relacionados
  • Elija el tipo apropiado. C/C++ pone el tamaño del valor en la variable size_t y pone el resultado de la operación del puntero en la variable ptrdiff_t
• constante nombrada
  • if (count == 76)¿Cuál es el significado de 76 en el medio, modifique 76 a la constante banaba_per_cake para una mejor comprensión?
  • El 76 mencionado anteriormente se llama Número Mágico, y algunas herramientas de detección de código lo detectarán
• Enfatizar código importante
  • Debe declararse en orden en la clase. Poner la información pública en primer lugar y la información de implementación privada en último lugar
  • Ocultar toda la información sin importancia
  • No ocultes código importante
  • Limite el número de sentencias condicionales anidadas
• Información relacionada con el grupo
  • Toda la información relevante debe estar en un solo lugar
  • Hay paquetes en Java que proporcionan agrupación
  • c/c++ tiene un espacio de nombres
• Proporcionar encabezado
  • Proporcione un bloque de comentarios en la parte superior del archivo para describir la función del archivo para que los mantenedores lo entiendan fácilmente.
  • La mayoría de las empresas o una gran cantidad de software de código abierto agregarán una declaración de derechos de autor o de código abierto a cada archivo fuente por consideraciones legales.
• Manejar los errores apropiadamente
  • Lugar adecuado para manejar errores. Si el disco IO es anormal, la excepción debe manejarse en el código que accede al disco. Esta excepción también provocará una excepción de archivo inaccesible, por lo que los errores de IO no se pueden manejar aquí.
  • No maneje los errores de E/S del disco en la sección final del código de la interfaz de usuario
• Escribe comentarios significativos
  • Solo agregue comentarios si no puede mejorar la claridad del código de ninguna otra manera
• Mejora tu propio nivel
  • Las habilidades de escritura se pueden mejorar leyendo más libros. Use un ojo crítico para examinar los artículos de otras personas, puede aprender a distinguir lo bueno de lo malo
  • Lo mismo es cierto para escribir código. Leer varios códigos excelentes (varias bibliotecas de código abierto) también mejorará tu nivel personal.

Cinco, comentarios de código

5.1 Función

• Los comentarios pueden distinguir el código bueno del código malo, la lógica tosca y compleja de los algoritmos claros y amigables, pero el papel de los comentarios no debe exagerarse.
• Los comentarios pueden ser la guinda del pastel, pero no pueden ayudarte en la nieve, y no puedes hacer que el código agrio sea dulce.

5.2 que es

• Desde un punto de vista sintáctico, es un bloque de código fuente ignorado por el compilador, y desde un punto de vista semántico, es una interpretación del código en el que se encuentra.
• Los lectores objetivo de los comentarios son las personas, y para mejorar la calidad de los comentarios deben satisfacer las necesidades reales de las personas al leer el código.
• Como programador responsable, es obligatorio escribir buenos comentarios.

5.3 Qué escribir

• explicar por qué, no cómo

• No repita el código en los comentarios.

• Al escribir comentarios densos para explicar el código, debe optimizar el código, no escribir los comentarios.

• Registrar algo inesperado, como un problema del sistema operativo

• El texto escrito debe ser veraz, valioso, claro y comprensible

5.4 Qué no escribir

• En el pasado, no escriba el código de la versión anterior, ahora hay un sistema de control de versiones, puede encontrar el código y los comentarios del pasado.

• Código no deseado, también tiene un sistema de control de versión de código,

• Arte ASCII, cualquier estilo que resalte partes del código no es recomendable, los ejemplos son los siguientes

  aBadExample(n, foo(wibble));
  //             ^^^
  //             My favorite function
  

• Al final del bloque de código, no es recomendable marcar el final del bloque de control con un comentario. Los editores modernos tienen una función de plegado de bloque de código, que es fácil de distinguir.

  // end if (a < 1)
  

5.4 Notas de uso

• Agregue TODO en los comentarios para marcar el trabajo inacabado
• Use comentarios Tenga cuidado de eliminar los comentarios obsoletos, cuando modifique el código, mantenga todos los comentarios alrededor del código
• Al mirar bases de código antiguas, es mejor no eliminar ningún comentario vacío que encuentre

6. Manejo de errores de código

6.1 Causa del error

Hay muchas razones para los errores, pero se pueden dividir aproximadamente en los siguientes tres tipos:

• Error de usuario, donde su amado programa ha sido maltratado por un usuario estúpido, que puede haber proporcionado una entrada incorrecta o haber hecho algo absurdo
• El programador está equivocado, los botones de usuario están todos correctos, pero el programa aún tiene un problema, que es causado por un error en el código escrito.
• En una situación inesperada, el usuario ingresa ok, y el programador no comete un error, pero en una situación inesperada, como que la red está desconectada, el disco duro está lleno

6.2 Informe de gestión de errores

El informe de errores es la difusión de información de errores al cliente.

• No lo informe, simplemente finalice el programa. Esta no es una buena manera, pero es simple.
• Juicio de valor de retorno, juzgue si se produce un error juzgando el código de estado devuelto por el valor de retorno de la función
• Excepciones, java usa excepciones para administrar errores
• Las señales son el equivalente de software de las interrupciones de hardware, el sistema operativo proporciona un controlador de errores razonable para cada señal, y c puede usar señales para manejar errores.

6.3 Manejo de errores

• errores de registro
• El programa necesita reportar errores al usuario cuando no hay nada que hacer, el usuario no puede ser bombardeado con errores todo el tiempo, y cuando hay una situación recuperable, no reportarlo. Por supuesto, hay algunos errores que solo el usuario puede manejar y deben ser informados de inmediato.
• A veces, los errores no se pueden resolver en el lado del código, o no sabe cómo resolverlos, entonces necesita pasar el error hacia arriba

6.4 Comprobación de errores

• Compruebe si el código ha realizado una limpieza de recursos, especialmente el cierre de algunos flujos
• Verifique los parámetros de la función de código, si se esperan
• Comprobar el estado del contexto de la llamada a la función

referencia

1. oficio de programacion