Lineamientos para escribir código bonito

Introducción

Cuando se estudia una carrera relacionada a la programación, se abordan diversas áreas que conforman la disciplina. Por ejemplo, en la Licenciatura en Ciencias de la Computación de la FaMAF, se estudian temas como algoritmos, lógica, matemáticas, bases de datos, sistemas operativos, ingeniería del software, paradigmas de programación, compiladores, entre otros más específicos. En la mayoría de estas materias, una actividad común es programar. Programar consiste en escribir secuencias de órdenes que una computadora puede ejecutar para realizar una tarea específica. Al programar, obtenemos programas los cuales podemos analizar desde múltiples dimensiones: ¿qué hace? ¿cómo lo hace? ¿es claro? ¿es testeable? ¿posee una buena modularización? ¿hay acomplamiento entre los módulos? ¿utilizan algún patrón de diseño? ¿es seguro?

Todos estos aspectos son fundamentales para desarrollar un software de alta calidad. Sin embargo, durante la formación académica suelen tratarse como elementos complementarios en lugar de objetivos centrales. Como consecuencia, no existe un momento donde los estudiantes puedan aprender estos principios, ni mucho menos una fuente de referencia concreta para escribir código con altos estándares.

Código Bonito

En matemática se habla de demostraciones elegantes. Estas demostraciones no solo son correctas sino también están bien estructuradas y utilizan los elementos adecuados para simplificar la tarea de demostración. Si bien el concepto de elegancia no está definido formalmente (algo raro si tenemos en cuenta que en matemática todo parte de una definición precisa), los matemáticos saben reconocer cuando se encuentran con una demostración elegante.

En programación queremos definir un término análogo: código bonito. Así como en matemática no existe una definición formal de elegancia, nosotros tampoco daremos una definición formal de bonito. Sólo diremos que un código es bonito si es claro, prolijo y está bien estructurado. En otras palabras, el código bonito está en la antípodas del código espaguetti. Como pasa con la elegancia en la matemática, todo programador con experiencia y conocimiento sabrá identificarlo y apreciarlo.

Lamentablemente, el código bonito no abunda. Años de experiencia en la industria y en las aulas han demostrado que el código bonito, en general, brilla por su ausencia. Este trabajo tiene como objetivo recopilar prácticas y recomendaciones ya conocidas, así como aportar nuevas ideas que ayuden a los programadores a escribir mejor código.

¿Por qué enseñar/aprender a programar es difícil?

Si tuviéramos que hacer una analogía entre la profesión de “programador” con otra, probablemente la mayoría de los programadores con experiencia estarían de acuerdo que programar se parece más a ser un albañil que un abogado. Un albañil construye desde cero o trabaja sobre obras ya empezadas. En el segundo caso, tirar todo lo construido no es una opción, hay que adaptarse a lo que se hizo, lo cual puede estar a veces muy bien, pero otras veces muy mal. En el mundo de la programación, muchas cosas son repetitivas, como levantar paredes en la construcción, pero sin estas cosas repetitivas, no habría una obra completa. Sumado a esto, toda obra tiene sus particularidades, que en muchas casos impactan en todo el proyecto, aún en las tareas más estándares.

Esta analogía entre programador-albañil da la clave para entender porqué enseñar/aprender a programar es difícil: programar es un oficio. La particularidad de los oficios es que se aprenden a través de la experiencia directa, uno puede leer libros y ver videos sobre como levantar una pared/programar, pero uno no aprenderá la tarea hasta dedicarle muchas horas a la misma. Es más, haber levantado miles de paredes no te hará necesariamente un buen albañil y, de forma similar, haber programado miles de lineas de código no te hará un buen programador. Esto se debe a que todo oficio tiene sus buenas prácticas, lineamientos que se deben seguir y el hacer por hacer no te garantiza aprenderlos.

En los oficios con más historia (albañil, zapatero, carpintero, etc), este problema se resuelve con la figura del maestro. Los maestros, son las personas con más experiencia en el oficio y tienen como responsabilidad el traspasar sus conocimientos a los aprendices del oficio. Este traspaso de conocimiento sucede en la práctica: mientras el aprendiz realiza alguna tarea, el maestro observa, y en base a lo que observa, brinda consejos, realiza correcciones y agrega explicaciones siempre que la situación lo requiera.

Volviendo al oficio de programar, podemos decir que en el mundo de la programación no existe la figura de “Maestro de la programación”. O al menos la misma no está generalizada. En las instituciones académicas, podemos afirmar con seguridad que esta figura no existe. Enumeremos algunas de las razones para pensar esto:

• Muchos docentes no ejercen el oficio de programar. Muchos docentes son académicos, entonces en su día a día no programan. Si no programan es difícil que sean “maestros de la programación”. Es más, probablemente tampoco sea para ellos una prioridad el enseñar a programar código bonito, tienen otras cosas importantes qué enseñar y eso no está mal.
• Corregir código es costoso. Supongamos ahora que tenemos un grupo de docentes que sí saben programar. Aún así revisar el código de los alumnos uno por uno sería imposible por el tiempo que eso llevaría. La tarea sería más imposible si le sumamos correcciones escritas y/o devoluciones uno a uno. Para complicar más la situación, sumémosle a esto el hecho de que las carreras informáticas cada vez se vuelven más populares -más alumnos- mientras que el número de docentes disminuye por encontrar ofertas laborales más atractivas.
• Los tiempos de los proyectos de programación son cortos. Los proyectos universitarios buscan enseñar conceptos claves de la informática (deadlocks, multiprocesamiento, simulaciones, protocolos TCP/UDP, programación de microcontroladores, etc) en pocos meses. Esos conceptos pueden enseñarse perfectamente realizando proyectos de programación que no siguen buenas prácticas. Forzar a los alumnos a seguirlas durante el proyecto - teniendo en cuenta el tiempo limitado con el que se cuenta - podría atentar con el objetivo principal del mismo.

¿Se podrían introducir la figura de Maestros de programación en las Instituciones académicas?

Entendemos que sí, pero esto podría requerir mucho más recursos humanos y financieros, qué no abundan en el mercado laboral informático/universitario del mundo de hoy. De todas formas, esta discusión está fuera del objetivo de este trabajo.

Para cerrar esta sección, traemos a colación un tema que cada tanto trae debate en las redes sociales: ¿Hace falta un título para ser programador? Por ser la programación un oficio, entendemos que no. Pero si quisiéramos construir un rascacielos, no contrataríamos a un albañil que aprendió a levantar paredes viendo videos en YouTube para diseñarlo.

Objetivo y organización de este trabajo

Programar bien es complejo. Hacerlo dentro de una industria lo es aún más, pues esto implica conocer la lógica de los procesos que ahí se desarrollan. Sumado a esto, todo software que se vende/utiliza cómo producto debe satisfacer muchos aspectos técnicos para que el mismo sea viable. Por ejemplo, aspectos relacionado al desempeño, seguridad, manejo correcto de los datos, etc.

El objetivo de este trabajo no es abarcar todo estos problemas. Sino que definir una linea base para programar bien. Para esto vamos a definir unos lineamientos que entendemos se puedan aplicar casi siempre en todo contexto. También queremos que este trabajo tenga impacto, es decir, muchas personas lo lean. Por esta razón, trataremos de ser lo más concretos posible en cada sección que presentemos. Creemos que este trabajo será sumamente valioso para las personas que están dando sus primeros pasos en informática y puede servir como material de referencia para materias donde se haga mucho foco en programar.

A lo largo de este trabajo vamos a presentar varias secciones:

• Sintaxis y Semántica
• Estructuras de Funciones
• Documentación y Comentarios
• Organización de proyectos
• Testing

En el capitulo de Sintaxis y Semántica pondremos énfasis en que al momento de escribir código, se tiene que ser lo más evidente posible con respecto al objetivo del código que uno está escribiendo. Para esto es fundamental la elección de buenos nombres y el uso de tipos. En Estructuras de Funciones daremos lineamientos para escribir funciones prolijas dado que son más fáciles de entender, utilizar y modificar. El capitulo Documentación será un capitulo muy corto sobre la importancia de documentar el código y lineamientos para hacerlo de forma correcta. En Organización de proyectos hablaremos de las capas lógicas que existen dentro de un proyecto y como estas organizan el código. Hablaremos también de Clases y de Inyección de Dependencias. Todo esto mediante la introducción de un proyecto pequeño de software. En el capitulo de Testing, seguiremos utilizando el mismo para hablar de testings unitario, de integración y end-to-end.

Tu opinion es importante para nosotros

Sí llegaste hasta acá, te contamos que nos interesa medir el impacto de este trabajo. Toda nuestras páginas tienen un formulario con 3 preguntas y nos sumaría un montón que las respondas. Gracias!