Filosofía de programación en C o "Como hacer programas C y no ahorcarse de un pino verde"
Me gustaría arrojar algunas luces para los principiantes, y para los no tan principiantes, sobre la forma "correcta" de escribir programas.
Cuando digo "correcta", no me refiero a la mejor, pues desde mi punto de vista no hay mejor, ni peor forma de programar, sino buenos o malos hábitos de programación.
Normalmente, la gente suele decir que Juanito es mejor que Pepito, y éste a su vez mejor que Rafalito, y todo porque Juanito ha escrito un Editor de Gráficos y Pepito una Contabilidad, mientras que Rafalito, escribió una simple Agenda.
Si viéramos el código fuente de los programas, quizá resulte que el de Rafalito es un código más limpio, estructurado y documentado que el que escribieron los otros, demostrando así que es más productivo (que de eso se trata). Así, él ha organizado su código de forma que si dentro de 4 años tiene que modificar algo, seguro que le resultará unas cien veces más fácil que a los otros, ahorrandose trabajo y tiempo, lo cual hace que sea el más recomendable de los tres para un proyecto en equipo.
Como sabes, el usuario normalmente no ve el código fuente de tus programas, pero tú si que lo ves. Y no solo lo ves, sino que a veces lo utilizas en otros programas o modificas algo del mismo, y si no eres capaz de leerlo y seguirlo para poder modificarlo con facilidad, al final, puedes acabar teniendo que reescribirlo casi todo, con lo cual perderás un tiempo precioso para hacer otras cosas. Eso sin hablar de los quebraderos de cabeza que te darán los nuevos errores que te vayan surgiendo. Tambíen hay otra cosa, si tú no eres capaz de seguir de una forma fácil tu propio código, ¿Crees que habrá alguien capaz de hacerlo?
Yo pienso, que además de claro, el código ha de escribirse de forma que sea posible añadirle cosas nuevas o introducir cambios con relativa facilidad. Esto no es nada fácil, ya que tampoco vas ha escribir un programa pensando que vas a meter tal o cual cosa dentro de seis meses o un año, pues no acabarías nunca. Pero bien diseñado, un programa puede dar mucho de sí.
Ante todo, deberías hacerte una especie de leyes a seguir y obligarte a ir cumpliendolas poco a poco al escribir tus programas, acercandote lo más posible a lo dicho. Ten en cuenta que el C es un lenguaje que no tiene características de comprobación de tipos y gestión de errores en tiempo de ejecución. Por ello, si sigues esas reglas o leyes, reducirás tus problemas de claridad, producción de errores y por tanto, la calidad de los programas que realices.
Yo tengo varias reglas, que ahora te expondré. No tienes por qué usar éstas aunque siempre es bueno emplear algunas tuyas y otras "prestadas". Las que aquí te indico, son el resultado de experiencias y consejos de escritores y programadores como Tanembaum, Wirth, McGuire, etc..; otras proceden de otros muchos programadores desconocidos e incluso hay algunas mías. De todas formas, con tu trabajo, tu mismo cosecharás alguna.
Bueno, aquí van:
- No debes dar nada por supuesto. Los usuarios pueden pulsar ENTER cuando deberian pulsar ESC.
- Los programadores que no permiten anticipar "teclazos" del usuario a la respuesta del sistema, deberían ser embreados y emplumados, o aún peor: condenados a usar su propio sistema. (Tanembaum)
- Lo último que se escribe de un programa es el interfaz de usuario, pero ésto no quiere decir que no sea uno de los elementos más importantes del programa, ya que es lo que los usuarios "ven" y "usan", es decir, los "mandos" del programa. Es quizá lo que más cuidado requiere en el diseño y por lo que los usuarios valoran más los programas.
- Jamás utilices código de otros que no entiendas del todo.
- Usa nombres descriptivos en las funciones y variables, así te darán una pista de lo que hacen.
- Usa las menos varibles globales posibles. De todas formas, deberias declararlas todas juntas, o encerrarlas en una estructura para saber las que tienes y dónde buscarlas.
- Procura no modificar las variables de control de los bucles.
- Las variables son eso: VARIABLES, y cuando deberían tener un valor, a veces tienen otro.
- Cuando declares un puntero, asígnalo a NULL instáneamente. De esa forma, si le metes un valor antes de darle una dirección, lo peor que te puede pasar es un error "NULL pointer assignment".
- Para remediar el error anterior, hay gente que usa punteros "dummy". Que son punteros con dirección válida y luego definen NULL para que apunte a él, con lo cual se ahorran el error y los problemas que conlleva. Mira el ejemplo:
/* DUMMY.H */
#include <stdio.h>
unsigned char dummy[512]; /* Declara el puntero de 512 */ /* bytes de espacio por si las */ /* moscas */
#undef NULL /* elimina el antiguo NULL */ #define NULL ((void *)&dummy) /* crea el nuevo */
Si haces por ejemplo:
int *p=NULL;
p=325;
p tendrá una dirección válida y no se colgará ni dará error
- Controla muy bien la memoria que utilizas, usa solo la necesaria y por supuesto, libérala al terminar su uso. Asi otros programas que la necesiten dispondrán de ella.
- Cuando cambies algo del entorno: modo de video, cursor, paleta de colores, etc.., vuelve a dejarlo como estaba antes. Un programa "educado" es más apreciado por los usuarios.
- Si pasas mucho rato buscando un error y no lo encuentras, lo más seguro es que esté en otra parte del código. (McGuire)
- Comprueba todos los errores posibles, incluso los que nunca fallan. Yo por ejemplo al entrar en las funciones que tienen punteros como parámetros, siempre compruebo que no sean NULL.
Ej.: int MiFuncion(int *punt) { ... if (punt==NULL) return ERROR_PTR_NULL; ... }
- No hay errores aleatorios, sino fallos en el control de errores.
- Los errores no desaparecen solos. (McGuire)
- Un programador avanzado no tiene menos errores que un principiante. Solo los encuentra y corrige más rápido.
- No compruebes las cosas dos veces, hazlo una o tres.
- Incluso en multitarea las cosas se hacen de una en una.
- Si después de un rato de programación, más que avanzas, retrocedes. Apaga y vuelve mañana.
- Documenta, documenta y documenta. Y si se entiende, mejor que mejor.
- Antes de empezar hoy, dale un vistazo a lo de ayer.
Y mi frase preferida:
- Poner a un monton de gente trabajando en el mismo proyecto, no les convierte en un equipo.
Si has tenido la paciencia suficiente como para llegar ha leer ésto hasta aquí, es que te interesa lo relacionado con la programación. Por ello te diré que no te agobies con los errores y recuerda otro dicho (soy el niño de los dichos)
"SI NO TIENES CAPACIDAD DE REIRTE DE TI MISMO Y COMPARTIR ESA RISA CON OTROS. NO CONSEGUIRAS TOLERAR LA PROGRAMACION POR MUCHO TIEMPO".
Cartas del Iluso. Revista SOLO PROGRAMADORES
Diviertete y que tengas pocos errores.
[Indice general] - [Sexo] - [linux] - [humor] - Chat entre usuarios - [miscelanea] - [Novedades] -
