Escribiendo el código fuente

(Este artículo forma parte del Curso de Programación en C)

La edición del código (o, como se dice a veces, “picar código”) es un acto cotidiano para el programador que no está exento de sus pequeños rituales (propios de cada uno) y de buenas costumbres (generales a todo el mundo). A continuación hablaremos de esas costumbres; los rituales, que se los busque cada cual. Pero antes, permítanme insistir una vez más: nunca empiecen a picar código sin haber planificado cuidadosamente su trabajo. Proceder de ese modo es la forma más segura de tener que tirar a la basura varios días de trabajo. Revisen este post si no saben de lo que hablo.

Escogiendo un editor de texto

A continuación nos referiremos al lenguaje C, pero todo lo que digamos puede aplicarse a la edición de código en cualquier otro lenguaje.

Para escribir el código nos puede servir cualquier procesador de textos que permita guardar el documento en forma de texto plano (sin códigos de control y formato propios de los procesadores avanzados, como Word o Writer). Existen multitud de procesadores de texto estupendos para programar en lenguaje C, pero el bloc de notas de Windows, definitivamente, no es uno de ellos (en realidad, no me imagino ninguna situación real en la que el bloc de notas pueda ser una herramienta estupenda).

La ventaja de estos procesadores es que resaltan, en diferentes colores y tipografías, las palabras clave, las funciones, las cadenas, los comentarios, etc, haciendo de este modo mucho más legible el código fuente. Algunos también revisan el equilibrado de los paréntesis y otros elementos emparejados. Ahí van algunos ejemplos de editores que son ligeros, útiles y soportan varios lenguajes: LopeEdit o UltraEdit (para Windows), gedit (para GNU/Linux con Gnome) o kate (para GNU/Linux con KDE). Y, por supuesto, el venerable emacs, que cuenta con una legión de incondicionales y anda por la versión 22 (!) cuando se escriben estas líneas.

Además, es habitual que los compiladores de C estén incrustados en un entorno de desarrollo más grande, que incluye también un editor. Por ejemplo, los compiladores de Borland (como Turbo C/C++, Borland C/C++ o C++ Builder) poseen un entorno integrado de desarrollo, que es un programa donde se unen el editor de texto, el compilador y el depurador en una sola aplicación controlada por un único interfaz, lo cual facilita mucho el trabajo. Otro entorno de desarrollo para Windows es Dev-CPP (éste, software libre). En GNU/Linux existen diferentes entornos integrados multilenguaje, todos con su correspondiente editor de texto, como Eclipse, KDevelop o Anjuta. En este artículo hablamos de cómo se usan este tipo de entornos. Ahora, sólo nos interesa el editor.

Recomendaciones para la edición del código

No están todas las que son, pero, como suele decirse, sí son todas las que están:

• No empiece a teclear código sin haber entendido bien el problema que se le plantea. Si éste es complejo, es imprescindible elaborar antes una descomposición modular en papel, resolviendo los módulos con pseudocódigo o con diagramas de flujo.
• Recuerde: comenzar a teclear a lo loco y sin pensar antes la solución detenidamente es la manera más segura de tardar el mayor tiempo posible en desarrollar un programa que, además, no funcione bien.
• Realice un diseño modular previo del programa. Recuerde que un módulo de más de 30 ó 40 líneas (aproximadamente) empieza a ser demasiado largo.
• Evite las variables globales. Evite las instrucciones GOTO. Realmente, no hay ninguna razón para usarlas, y más aún si ha diseñado correctamente el programa.
• Elija bien el nombre de los identificadores (variables, constantes, funciones…), le ahorrará muchos quebraderos de cabeza. No llame a su variable e si puede llamarla edad, pero tampoco la llame edad_del_jugador_1 si no es absolutamente imprescindible. Los identificadores deben ser significativos pero no excesivamente largos.
• Use la identación del texto, es decir, deje las sangrías necesarias para facilitar su lectura.
• Use espacios y líneas en blanco siempre que considere que facilita la lectura. Es mucho más fácil de leer if (x > 5 + c) que if(x>5+c).
• Desarrolle su propio estilo de escritura, siempre que sea razonable, y sígalo en todo el programa. Si está colaborando con otros programadores, use el estilo que hayan conveniado entre todos.
• Sea generoso documentando el código fuente. Mejor que sobren comentarios que no que falten. Ante la duda, comente. En particular, es importante comentar cada función: qué hace, qué parámetros recibe, qué significan los valores de los parámetros y qué valores devuelve.
• Si está programando en C, guarde el código fuente en archivos de texto cuya extensión sea “.c” (por ejemplo: “ejercicio.c”). Fíjese que “.c” no es lo mismo que “.cpp”

Cómo NO se debe programar

No me resisto a mencionar un desternillante documento de la Universidad de Oviedo, donde, con abundante sarcasmo y mala uva, el autor desgrana las malas costumbres más habituales de los estudiantes de programación a la hora de programar. El documento completo lo pueden encontrar aquí. No tiene desperdicio, y hasta los programadores más experimentados sacarán algo de él, o, al menos, esbozarán una sonrisa… aunque no le recomiendo su lectura si no tiene usted sentido del humor.

Les extracto algunas de sus desquiciadas recomendaciones:

• Ignore los mensajes de error: los compiladores, los sistemas operativos, etc, emiten mensajes de error sólo para que los usen sus creadores, o para justificar sus sueldos.
• Escriba el código directamente sin pensar: ¿Qué es lo que estamos construyendo? Un programa. ¿Qué es lo único imprescindible en un programa? El código. ¿Qué es lo que de verdad funciona? El código. No hay que perder ni un minuto en usar medios arcaicos como lápices, bolígrafos o papel.
• Aunque el código no compile o no funcione, siga escribiendo: es sabido que los mensajes de error son una interrupción inadmisible, una traba estúpida a nuestro trabajo. ¿Qué puede hacer si tiene un error de compilación? Ya hemos visto que leérselo y comprenderlo no es una opción válida. Se puede intentar hacer algún cambio aleatorio en el código fuente, a ver si hay forma de engañar a ese estúpido compilador. Pero si eso no funciona, no pierda más tiempo. NO, no caiga en la tentación de leer el mensaje de error o intentar comprenderlo.
• Construya enormes porciones de código sin compilar / ejecutar / probar: no compile con frecuencia; no dé pasos pequeñitos. Escriba miles de líneas de código, y ya después se compilará. Así será mucho más entretenido buscar los errores de compilación y arreglar el código, lo que constituye un excelente ejercicio.