7 consejos para escribir código limpio y mejor en 2020

La ingeniería de software no se trata solo de aprender un idioma y construir algún software. Como ingeniero de software o desarrollador de software, se espera que escriba un buen software . Entonces la pregunta es ¿qué hace un buen software?. Un buen software se puede juzgar leyendo algún fragmento de código escrito en el proyecto. Si el código es fácil de entender y cambiar , definitivamente es un buen software y a los desarrolladores les encanta trabajar en eso.

7-Tips-To-Write-Clean-And-Better-Code-in-2020

Es algo común en el desarrollo que nadie quiera continuar un proyecto con un código horrible o desordenado (a veces se convierte en una pesadilla…). A veces, los desarrolladores evitan escribir código limpio debido a la presión de la fecha límite. Se apresuran a ir más rápido, pero lo que sucede en realidad es que terminan yendo más lento. Crea más errores que necesitan corregir más tarde volviendo al mismo código. Este proceso lleva mucho más tiempo que el tiempo dedicado a escribir el código. Un estudio ha revelado que la proporción de tiempo dedicado a leer código frente a escribir está muy por encima de 10 a 1 .

Ratio-of-Time-Spent-Reading-Code-Versus-Writing

No importa si eres un programador principiante o experimentado, siempre debes tratar de convertirte en un buen programador (no solo un programador…). Recuerde que usted es responsable de la calidad de su código , así que haga que su programa sea lo suficientemente bueno para que otros desarrolladores puedan entenderlo y no se burlen de usted cada vez para entender el código desordenado que escribió en su proyecto.

Qué hace un código limpio: antes de discutir el arte de escribir un código limpio y mejor, veamos algunas características del mismo…

  1. El código limpio debe ser legible . Si alguien está leyendo su código, debería tener la sensación de leer poesía o prosa.
  2. El código limpio debe ser elegante . Debe ser agradable de leer y debe hacerte sonreír.
  3. El código limpio debe ser simple y fácil de entender. Debe seguir el principio de responsabilidad única (SRP) .
  4. El código limpio debe ser fácil de entender , fácil de cambiar y fácil de cuidar .
  5. El código limpio debe ejecutar todas las pruebas .

“El código limpio es simple y directo. El código limpio se lee como una prosa bien escrita. El código limpio nunca oscurece la intención del diseñador, sino que está lleno de abstracciones nítidas y líneas de control sencillas”.
-Grady Booch ( autor de Análisis y diseño orientado a objetos con aplicaciones )

¿Cómo escribir código limpio y mejor?

1. Usa nombres significativos

Estarás escribiendo muchos nombres para variables, funciones, clases, argumentos, módulos, paquetes, directorios y cosas por el estilo. Acostúmbrese a usar nombres significativos en su código. Independientemente de los nombres que mencione en su código, debe cumplir tres propósitos: qué hace , por qué existe y cómo se usa . Por ejemplo:

int b; // number of users.

En el ejemplo anterior, debe mencionar un comentario junto con la declaración del nombre de una variable que no es una característica de un buen código. El nombre que especifique en su código debe revelar su intención. Debe especificar el propósito de una variable, función o métodos. Entonces, para el ejemplo anterior, un mejor nombre de variable sería: – int número_de_usuarios . Puede llevar algo de tiempo elegir nombres significativos, pero hace que su código sea mucho más limpio y fácil de leer para otros desarrolladores y para usted mismo. Además, trate de limitar los nombres a tres o cuatro palabras.

2. Principio de responsabilidad única (PRS)

Las clases, las funciones o los métodos son una buena manera de organizar el código en cualquier lenguaje de programación, por lo que cuando escribe el código, realmente debe tener cuidado de cómo escribir una función que comunique su intención. La mayoría de los principiantes cometen el error de escribir una función que puede manejar y hacer casi todo (realizar múltiples tareas). Hace que su código sea más confuso para los desarrolladores y crea problemas cuando necesitan corregir algunos errores o encontrar algún fragmento de código. Entonces, cuando esté escribiendo una función, debe recordar dos cosas para que su función sea clara y fácil de entender…

  1. Deben ser pequeños.
  2. Deben hacer una sola cosa y deben hacerlo bien.

Los dos puntos anteriores mencionan claramente que su función debe seguir el principio de responsabilidad única . Lo que significa que no debería tener una estructura anidada o no debería tener más de dos niveles de sangría. Seguir esta técnica hace que su código sea mucho más legible y otros desarrolladores pueden entender o implementar fácilmente otra función si su función cumple una tarea específica.
Además, asegúrese de que su función no tenga más de tres argumentos. Más argumentos realizan más tareas, así que trate de mantener los argumentos lo menos posible. Pasar más de tres argumentos hace que su código sea confuso, bastante grande y difícil de depurar si hubiera algún problema. Si su función tiene una declaración try/catch/finally, cree una función separada que contenga solo las declaraciones try-catch-finally.
Cuide también el nombre de su función. Use un nombre descriptivo para su función que debe especificar claramente lo que hace.

Ejemplo:

function subtract(x, y) {
    return x - y;
}

En el ejemplo anterior, el nombre de la función muestra claramente que su propósito es realizar la resta de dos números, también tiene solo dos argumentos. Obtenga más información sobre cómo escribir una buena función en el enlace 7 principios comunes de programación que todo desarrollador debe seguir y el principio SOLID .

3. Evite escribir comentarios innecesarios

Es común que los desarrolladores usen comentarios para especificar el propósito de una línea en su código. Es cierto que los comentarios son realmente útiles para explicar lo que hace el código, pero también requieren más mantenimiento de su código. En el código de desarrollo, muévase aquí y allá, pero si el comentario permanece en el mismo lugar, puede crear un gran problema. Puede crear confusión entre los desarrolladores y también se distraen debido a comentarios inútiles. No es que no deba usar comentarios en absoluto, a veces es importante, por ejemplo… si está tratando con una API de terceros donde necesita explicar algún comportamiento allí, puede usar comentarios para explicar su código pero no escriba comentarios donde no es necesario.
Hoy en día, la sintaxis de los lenguajes de programación modernos es similar al inglés y eso es lo suficientemente bueno para explicar el propósito de una línea en su código. Para evitar comentarios en su código, use nombres significativos para variables, funciones o archivos.

Un buen código es su propia mejor documentación. Cuando esté a punto de agregar un comentario, pregúntese: «¿Cómo puedo mejorar el código para que este comentario no sea necesario?» Mejore el código y luego documéntelo para hacerlo aún más claro.
-Steve McConnell

4. Escriba un código legible para las personas

Muchas personas, especialmente los principiantes, cometen errores al escribir un código que escriben todo en una sola línea y no dan espacios en blanco, sangría o saltos de línea adecuados en su código. Hace que su código sea desordenado y difícil de mantener. Siempre existe la posibilidad de que otro ser humano acceda a su código y tenga que trabajar con él. Pierde el tiempo de otros desarrolladores cuando intentan leer y comprender el código desordenado. Así que siempre preste atención al formato de su código. También ahorrará tiempo y energía cuando regrese a su propio código después de un par de días para hacer algunos cambios. Así que asegúrese de que su código tenga la sangría, el espacio y los saltos de línea adecuados para que sea legible para otras personas. El estilo de codificación y el formato afectan la capacidad de mantenimiento de su código.

// Bad Code
class CarouselRightArrow extends Component{render(){return ( <a href="#" className="carousel__arrow carousel__arrow--left" onClick={this.props.onClick}> <span className="fa fa-2x fa-angle-left"/> </a> );}};
  
// Good Code
class CarouselRightArrow extends Component {
  render() {
    return (
      <a
        href="#"
        className="carousel__arrow carousel__arrow--left"
        onClick={this.props.onClick}
      >
        <span className="fa fa-2x fa-angle-left" />
      </a>
    );
  }
};

El formateo de código tiene que ver con la comunicación, y la comunicación es la primera orden del día del desarrollador profesional.
-Robert C. Martin (tío Bob)

5. Escribir pruebas unitarias

La prueba de unidad de escritura es muy importante en el desarrollo. Hace que su código sea limpio, flexible y mantenible. Hacer cambios en el código y reducir errores se vuelve más fácil. Hay un proceso en el desarrollo de software que se llama Test Driven Development (TDD) en el que los requisitos se convierten en algunos casos de prueba específicos y luego se mejora el software para pasar nuevas pruebas. Según Robert C. Martin (tío Bob), las tres leyes de TDD demuestran…

  1. No se le permite escribir ningún código de producción a menos que sea para pasar una prueba de unidad fallida.
  2. No se le permite escribir más de una prueba unitaria de lo suficiente para fallar, y las fallas de compilación son fallas.
  3. No se le permite escribir más código de producción que el suficiente para pasar la prueba unitaria fallida.

Test-Software-Developement

Después de subirme al carro de las pruebas unitarias, la calidad de lo que ofrezco ha aumentado hasta el punto de que la cantidad de respeto que recibo de mis colegas me hace sentir incómodo. Creen que estoy bendecido o algo así. No estoy dotado ni bendecido ni tan talentoso, solo pruebo mi código.
– Justin Yancey, ingeniero sénior de desarrollo de sistemas, Amazon

6. Tenga cuidado con las dependencias

En el desarrollo de software, realmente debe tener cuidado con sus dependencias. Si es posible, sus dependencias siempre deben ser una dirección singular. Significa… digamos que tenemos una clase de cocina que depende de una clase de lavavajillas. Siempre que el lavavajillas no dependa también de la clase de cocina, se trata de una dependencia unidireccional. La clase de cocina solo usa el lavavajillas, pero al lavavajillas realmente no le importa y cualquiera puede usarlo. No tiene que ser una cocina. Este ejemplo de dependencia unidireccional es más fácil de administrar; sin embargo, es imposible tener siempre una dependencia unidireccional, pero debemos intentar tener tantas como sea posible. Cuando la dependencia va en múltiples direcciones, las cosas se complican mucho más. En la dependencia bidireccional, ambas entidades dependen una de la otra, entonces tienen que existir juntos aunque estén separados. Se vuelve difícil actualizar algunos sistemas cuando sus dependencias no forman una dirección singular. Así que siempre tenga cuidado con la gestión de sus dependencias.

7. Haz que tu proyecto esté bien organizado

Este es un problema muy común en el desarrollo de software que agregamos y eliminamos tantos archivos o directorios en nuestro proyecto y, a veces, se vuelve complicado y molesto para otros desarrolladores entender el proyecto y trabajar en eso. Estamos de acuerdo en que no se puede diseñar una organización perfecta de carpetas o archivos el primer día, pero más adelante, cuando su proyecto se vuelve más grande, realmente debe tener cuidado con la organización de sus carpetas, archivos y directorios. Una carpeta y un archivo bien estructurados aclaran todo y es más fácil comprender un proyecto completo, buscar alguna carpeta específica y realizar cambios en ella. Así que asegúrese de que la estructura de su directorio o carpeta esté organizada (lo mismo se aplica a su código también).

Los mejores libros para entender cómo escribir un código limpio y mejor:

Publicación traducida automáticamente

Artículo escrito por anuupadhyay y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *