Cómo hacer tu código limpio y bonito

Tener un código que a todos les parezca entendible no es siempre lo más fácil de hacer. Cada quien tenemos una forma de pensar y de plasmar esas ideas en un archivo, pero deberíamos preocuparnos cada día más por eso, ya que habla de la profesionalidad y sobre todo de la limpieza que tenemos con el código. Tu eres de la forma en que está escrito tu código, así que un código mal hecho reflejará pereza o poca importancia por la legibilidad.

Encontré un buen artículo de Ravi Shankar Rajan en donde nos da algunos tips sobre cómo hacer tu código más limpio y bonito, muchos de los tips creo que los conocen, pero igual y otros no tanto. A continuación les resumo brevemente de qué trata cada uno de ellos.

Nombres coherentes

Ya sea que escribas el nombre de las cosas deEstaForma o de_esta_otra, escoger nombres es toda una hazaña. Los más flojos escogerán nombres genéricos como ‘x’ o ‘i’ o ‘variableN’ pero solo los que se preocupan de que su código sea entendible se tomarán el tiempo para nombrar las cosas. Las funciones, variables, estructuras y clases deberían nombrarse según su funcionamiento, o lo que esperamos encontrar dentro de ellas.

Las funciones deberían hacer solo una cosa

De la misma forma que una variable debería alamacenar ciertos tipos de variables, las funciones deberían ejecutar solamente una cosa. Esto trata del principio de separación de alcances, es decir, que una función debería ser lo más genérica posible para ser usada en muchos contextos, pero debería entregar una sola respuesta o resultado. Una función que suma dos valores no debería hacer otra cosa que tomar dos números, evaluarlos para saber si son números y a continuación hacer la operación matemática. Una función que cumple con varias operaciones debería ser separada en funciones adicionales y después una que mande a llamar la indicada. Es un ejemplo sencillo que útil cuando se tiene que desmenuzar una función para hacerlas más simples y entendibles.

Los comentarios ayudan, no explican

Los comentarios deben servir para ayudar al programador a entender brevemente qué espera de la función. Los comentarios no deberían explicar el paso a paso de la función o procedimiento, ya que interferiría con el punto anterior. Bien dicen que si no puedes explicar algo con pocas palabras es porque no lo entendiste, y aquí se aplica igual. Si no puedes explicar de forma muy breve qué es lo que pasa es porque tampoco sabes qué estás programando.

Formatea tu código

Cuidar los espacios, identación y estructura siempre dará una buena alineación en tu código. Esto permite que cualquier usuario pueda leer de forma continua tu código, sepa detener la mirada cuando es necesario, y continuar cuando así se indique. Un código que no está identado adecuadamente siempre va a hacer que el desarrollador se detenga a ver donde termina la llave o donde está la siguiente sentencia. Esto también aplica a procedimientos que van anidados como condicionales. No deberíamos tener más de dos o tres niveles de identación, ya que rompería con el consejo #2 al empezar a anidar código que el desarrollador tiene que ir desmenuzando por nivel.

Los bloques de código no deben contener todo tu código

Los bloques como condicionales o try-catch nunca deben contener todo tu código porque es quizá de las prácticas de código más pobres que alguien puede implementar. Hay muchísimas formas de salir de un condicional o un try-catch sin caer en lo anterior. Una estrategia es saber detener el código o salirse de una función cuando no se cumplen condiciones o hay excepciones que impiden que las acciones continuen.

Fuente: hackernoon