Buenas prácticas programando.

¿Quién no se ha encontrado con un caos, mientras lee un código? o... ¿cuando estás intentando leer el código de alguien, sólo ves nombres que no sabes qué hacen, o a qué hacen referencia?... Pues bienvenido al club. Así es mi día día, el enfrentarme a código que no entiendo o que no sé bien que ejecuta, y te tiras horas hasta que logras saber que hace. Todos sabemos la teoría de escribir un código limpio y claro, (suele ser algo que se comenta mucho cuando estudias o en el ámbito laboral) pero que no siempre se llevan a cabo. En esta publicación resumiré algunas de las más habituales, y que haciéndolas bien, creo que nos ayudarían a la hora de enfrentarnos al código, ahorrándonos tiempo y sobre todo, dolores de cabeza. Esto no sólo ayudará a otros, sino a nuestro "yo del futuro" cuando quiera retomar algo.

Nomenclatura.

El mejor nombre que le puedes poner a algo, es un nombre que haga referencia a lo que hace o que almacena. Muchas veces vemos variables que son:

int zx = 23;
    return getZx(valu -zx);

¿Qué es zx? ¿Para que es getZx()? No sería mejor...

int edadPadre = 23;
    return getDameElanioNacimientoi(valorActual - edadPadre); 

No sé vosotros.... pero yo de la segunda forma, me entero a la perfección de lo que hace la función y los valores que puede almacenar las variables.

Cuanto más explicativo sea el nombre mejor.Obviamente no vas a poner como nombre, uno que ocupe dos líneas.... siempre dentro de unos límites razonables, y que tú, fácilmente, entiendas al leerlo (o al leerlo otra persona). Haciendo esto bien, no es necesario realizar muchos comentarios por el código, de hecho suele desaconsejarse realizarlos (sólo usarlos cuando sea realmente necesario), teniendo una buena practica a la hora de llamar a las cosas por su nombre, esto no se haría muy necesario. Es importante siempre seguir los estándares.

Métodos cortos y concisos.

Es importante también, hacerte métodos (o funciones) cortos, que se encarguen de una cosa en concreto. Si se encargan de varias cosas... mal. Si estos métodos contienen 0 parámetros mejor que mejor. Deben ser muy concisos y siempre intentar hacer el código que se lea fácilmente de arriba hacia abajo. Es decir, si tenemos un método que necesita de otro, el segundo método debería estar inmediatamente después, y si necesitases de otro método, éste debería estar debajo del que dependa... Nada de poner métodos cada uno en un sitio, para luego volverte loco, mientras buscas y procesas lo que estás leyendo....

public static double numeroAleatorio(int maximo, int minimo) {
    double numero = Math.round(Math.random() * (maximo - minimo) + minimo);
    return numero;
}
public static int dameNumero(String frase) {
    String num = JOptionPane.showInputDialog(frase);
    return Integer.parseInt(num);
}

La indentación del texto y estilo al escribir.

Para entender bien el código, muchas veces se hace necesario que se separen bien las sentencias, y que se lleve un buen orden. Además es importante que el código lleve armonía a la hora de escribir. Muchas veces encuentras que la indentación no es muy buena o a la hora de escribir alterna diferentes formas de expresar algo, por ejemplo:

if(loQueSeaAquiDentro) {
    //TODO
}
if(OtroEjemplo){
    //TODO
} 

Cómo veis es un if que está escrito de diferente forma... A veces esto provoca que sea algo más complicado de leer el código. Python, por ejemplo, a la hora de escribir, es bastante especial en este sentido, lleva unas normas a la hora de hacer por ejemplo la indentación, el tamaño máximo de una línea es de 79 caracteres, separa las funciones no anidadas y las definiciones de clases con dos líneas en blanco...

 

Realiza test.

Siempre que hagas métodos o funciones, es importante testearlo, de forma que ese método pase todos los test sin problemas (intentando abarcar todas las casuísticas). Esto hará que el código sea más fiable y que no nos de problemas a la hora de ejecutarlo (porque habremos detectado los problemas en estos test).

No repetir código.

Nos encanta usar el Ctrl+C y el Ctrl+V y ya si algo funciona... lo pegamos por todos los lados.... Esto es una mala práctica. Si en un futuro queremos cambiar algo de "eso que hemos copiado y pegado en 20 sitios" nos tocará cambiarlo en 20 sitios, o quizás, en ese momento de hacer Ctrl+V se nos vaya el dedo o copiemos algo que no debemos y entonces, adivina .... Es mejor encapsular parte del código que estamos usando y así la aprovecharemos cuando sea necesario.

Documentación.

Si algo es importante es la documentación esto, nos permitirá aprender a realizar cosas que no sabíamos, a entender un proyecto, a realizar aquellos que nos piden con la documentación que nos puede pasar el funcional, sobre unos requerimientos específicos (que debe ser clara, concisa y bien explicada, para que podamos llevar a cabo la tarea que se nos pide. Es importante también la documentación que podamos generar nosotros por nuestra cuenta. En algún momento nos iremos de vacaciones, o cambiaremos de empresa....creo que es importante dejar constancia de lo que hemos hecho y cómo lo hemos hecho. Es fundamental compartir los conocimientos. Esto hará que la evolución de proyecto sea más rápida, sin pérdida de tiempo, seremos más felices todos, (ya que no estaremos desquiciados averiguando cosas) y sobre todo aprenderemos unos de otros. Es importante el explicar al resto cosas que igual no saben o les pueden ayudar. "Nunca te acostarás sin saber algo más" y Compartir es vivir deberían ser lemas por excelencia.

Os voy a dejar el "ZEN de python" sólo tendréis que ejecutar en vuestro terminal : **python** y más tarde la instrucción

import this
y veréis el siguiente texto... que seguro que os ayudará

import this The Zen of Python, by Tim Peters
Beautiful is better than ugly.Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

Aquí os lo dejo traducido...

Bonito es mejor que feo Explicito mejor que implícito Simple mejor que complejo Complejo es mejor que complicado Plano mejor que anidado Disperso mejor que denso La legibilidad cuenta Los casos especiales no son lo suficientemente especiales como para romper las reglas Aunque la practicidad supera la pureza Los errores nunca se deben ocultar Al menos que se silencien explicitamente Ante la ambigüedad, rechaza la tentación de adivinar. Debe haber una forma obvia de hacerlo Aunque esa manera no puede ser obvia al principio Ahora es mejor que nunca Aunque nunca es mejor que ahora Si la implementación es difícil de explicar es una mala idea Si la implementación es fácil de explicar podría ser buena idea Los espacios de nombres son una gran idea. Vamos a hacer más de esos

También os dejo el enlace a un libro muy interesante sobre las buenas practicas, escrito por Robert C. Martin Codigo Limpio