¿Qué quieren decir los ingenieros / desarrolladores de software con el código de calidad?

El código de calidad es como una prosa inglesa bien escrita. En realidad, utilizas las mismas reglas para juzgar la calidad del código que la calidad de la prosa. Aquí hay algunos consejos.

  • Breve: el código de calidad habla en oraciones claras, breves y declarativas, al igual que el buen inglés. No es largo y complicado. Eso significa líneas cortas (menos de 80 caracteres) y funciones breves (menos de 20 líneas). Las declaraciones de flujo de control no están profundamente anidadas. Si tiene más de dos capas de bucle, más una capa de lógica if / else, su código es complicado y difícil de seguir. (Sí, si está atravesando una matriz tridimensional, habrá tres capas de bucle, pero ¿con qué frecuencia sucede eso realmente?) El código con demasiadas capas de anidamiento también tiende a ser más largo, violando la regla de brevedad anterior . ¿Una sola línea larga o una función de más de 20 líneas siempre es incorrecta? No, pero es algo de qué preocuparse.
  • Directo: el código de calidad destaca directamente, al igual que la buena prosa en inglés. No es sutil No insinúa ni implica. No anda por las ramas. Los efectos del código son directos. No se basan en los efectos secundarios o el estado global. Una función dada hace una sola afirmación. No hace tres cosas diferentes. El buen inglés usa nombres más que pronombres. Un buen código usa variables más que referencias o punteros. Los nombres son más directos y menos confusos.
  • Metáfora: el código de calidad, como la bella prosa en inglés, utiliza metáfora y símil. En lugar de descripciones prosaicas de largo aliento, un buen código usa nombres de funciones que describen brevemente lo que hace un bloque de código sin forzar innecesariamente al lector a ver cómo lo hace. Esto mejora enormemente la legibilidad del código. Del mismo modo, los nombres de las variables pueden ser descriptivos de para qué sirve la variable, en lugar de cómo se implementa. A veces es útil el uso de convenciones metafóricas comunes, como usar i para el índice del bucle externo y j para el índice del bucle interno. Esta es una decisión judicial.
  • Eficiente: el código de calidad utiliza un algoritmo eficiente y estructuras de datos eficientes. En general, el algoritmo debe ser obvio por el código, de modo que el código se parezca a todos los demás códigos que usan el mismo algoritmo. El código y los comentarios hacen referencia al algoritmo para mejorar la comprensión de cualquier lector que lo conozca y para enseñar el algoritmo a cualquier lector que no lo conozca. Si el código usa un algoritmo menos eficiente, el lector debe preguntarse por qué fue codificado de manera ineficiente, y si se necesitaba o no eficiencia en alguno de los varios lugares que pueden haber invocado el código. Esto distrae de la comprensión.
  • Anotado: Un buen libro tiene una buena tabla de contenido, índice, lista de figuras, notas al pie, etc. Asimismo, el buen código tiene comentarios en lugares donde el código no es lo suficientemente claro. Es cierto que un código muy bien escrito no requiere demasiados comentarios. No es cierto que un buen código no tenga ningún comentario. El código es un lenguaje de muy bajo nivel, apropiado para decirle a un robot muy estúpido exactamente cómo ejecutar el código. No es un nivel de detalle apropiado para explicar por qué un diseño se ve como se ve, o cómo una pieza de código encaja en un sistema más grande. Los comentarios son muy parecidos a las notas al pie de página, explicando fragmentos de código que son oscuros o poco intuitivos. Al igual que las notas al pie, los comentarios pueden ser utilizados en exceso.

Desearía que hubiera un premio Pulitzer por el código, alguna recompensa por escribir un código hermoso, como si hubiera una gran prosa en inglés. Un gran código es como la poesía. Pero por cada poema de código épico, hay 10,000 drab tomes de código no inspirado y difícil de leer.

Hay muchas maneras diferentes en que las personas pueden clasificar esto, pero lo pondría en algunas categorías como se escribe a continuación:

Es facil de entender

Esto es mucho más difícil de lo que piensas. Algunas personas pueden pensar que están escribiendo un código fácil de entender cuando, en realidad, se pierden en su propio mundo mientras escriben y no tiene sentido para otras personas.

Esto también es útil cuando regresas después de 6 meses y tienes que corregir un error. El código debe tener rutas lógicas claras que sean fáciles de seguir y fáciles de entender.

Nombres de variables obvias

No entiendo por qué las personas encuentran esto tan difícil de hacer, pero las variables en el código deben tener un sentido lógico y estructurado que sea fácil de entender para otras personas.

No muy compacto

Este punto es obviamente discutible. Algunas personas pueden decir que lo prefieren. Solía ​​tener un enfoque más exagerado de mi espacio y fui un poco exagerado cuando estaba aprendiendo. Ahora mantengo un espacio razonable para que cuando vea el código pueda ver claramente cómo está configurado en secciones.

Sangría correcta

Esto puede hacer que algo que sea masivo y complicado (una gran consulta, por ejemplo) sea muy, muy fácil de entender. El código siempre debe tener una sangría correcta para facilitar que la persona entienda las secciones.

Escribir comentarios correctos

A veces hay alguna lógica (o cambios realizados) que son complicados. Cuando esto sucede, las cosas deben comentarse correctamente para permitir que las personas entiendan todo lo que sucede.

Los comentarios deben hacerse en los lugares correctos, no en cada línea que explique puntos obvios, de lo contrario los comentarios en sí mismos se volverán ilegibles y perderán su importancia.

Eficiente

Hasta este punto, estaba cubriendo puntos relacionados con la “belleza” del código. Esto se debe a que supongo que el código se ha escrito utilizando el mejor método para la eficiencia. No deberías hacer sangrías masivas de sentencias IF para siempre y realizar código dentro de bucles grandes cuando podrían hacerse de una mejor manera. Asumí que este punto era bastante obvio, así que me concentré en las áreas más “difíciles”.

Resumen

Puede ser bastante difícil igualar todos los puntos anteriores, especialmente a medida que los equipos comienzan a expandirse y obtienes programadores que tienen diferentes estilos y enfoques diferentes. Es por eso que es importante asegurarse de que todo el equipo converja con un estándar correcto y un código de compilación que sea similar y fácil de entender para todo el equipo. No hay nada peor que tener un código escrito por una persona y son las únicas personas capaces de depurarlo porque es extremadamente complicado y difícil de entender.

Espero que esto te dé una idea interesante.

El código de calidad es un código que otros desarrolladores, que pueden considerarse junior, pueden leer, comprender y mantener fácilmente. Debe ser autodocumentado; sin comentarios. Las variables y funciones deben estar bien nombradas para describir lo que hacen y los valores que poseen / devuelven.

En un mundo perfecto, el código de mejor calidad debería leerse como una novela romántica.