Consejos para programar en C

domingo, julio 30, 2006

Manejo de errores

  • Es muy importante detectar a tiempo que ha habido un error cuando se ejecuta nuestro programa y en ese momento terminar la ejecución para evitar qué seguir con ella nos lleve a errores más graves que puedan "colgar" la máquina, por ejemplo.

  • Es recomendable que la salida del programa vaya a stdout (o salida estándar) y los errores vayan a stderr. Por ejemplo:

fprintf(stdout, "La palabra es aceptada\n”);

fprintf(stderr, "Los argumentos de entrada son invalidos\n");

En la lectura de ficheros

Cuando se accede a un fichero para leerlo nos pueden ocurrir los siguientes casos que debemos evitar;


  • Se intenta leer un fichero que no existe y en vez de dar error y salir del programa se continúa y al final el programa termina fallando.

  • Nuestro programa no detecta el final de fichero y se cuelga. Con las funciones de detección de final de fichero y con las funciones de lectura de fichero debemos poder detectar cuando terminamos de leer un fichero.

  • Cuando se está leyendo un fichero no se comprueba que las cosas que se desean leer estén como se espera y esto puede producir que nuestro programa "cuelgue" la máquina. Cuando se está leyendo de un fichero y rellenando con lo que lee unos datos se debe comprobar que se lee lo deseado para evitar problemas.

En el paso de argumentos al main

  • Si nuestro programa puede recibir parámetros a la hora de ejecutarse y estos no son introducidos, lo más lógico es, o bien pedirlos a continuación, o dar un error diciendo cual es la sintaxis de lo que se debería haber introducido - Y para completar podría el programa mostrar una ayuda de los parámetros que acepta y su uso a través del parámetro -? o -h tras el nombre del programa.

  • Si el programa espera argumentos en línea de comandos, hay que asegurarse de que el usuario los ha introducido comprobando el valor de argc.

Trabajo con memoria dinámica

  • Lo primero que tenemos que tener en cuenta es que tenemos en nuestro fichero los includes: y .

  • Siempre que usemos una variable definida como puntero hay que reservar memoria, el siguiente ejemplo sería erróneo ya que no se le da memoria en ningún sitió al puntero a char:

char *cadena;

y después:

scanf("%s", cadena);


  • Se tiene que reservar la memoria para la cadena de caracteres utilizada.

  • Si el programa tiene que parar la ejecución por un error, se debe liberar la memoria reservada hasta el momento.

Trabajo con includes (.h);

  • . No se puede poner ningún include del tipo

  • Indicando el path completo al archivo: #include “a:\mifichero.h” Se pone de forma relativa: #include “mifichero.h”

  • De un archivo de código: #include “mifichero.c” Nunca un .c en un include.

  • De un archivo nuestro, entre "<" y ">": #include Se pone con comillas: #include “mifichero.h”

Siendo mifíchero.h o mifíchero.c ficheros creados por nosotros. Lógicamente no nos referimos a stdlib.h o stdio.h, u otros includes del sistema.


  • No olvidar poner ningún include, es típico olvidar , (sin estos includes el programa puede dejar la maquina “colgada” a la hora de ejecutarse). Para saber si nos olvidamos poner algún include hay que configurar el Turbo C para que nos avise con un “warning” de ello. Lo más cómodo y recomendable es activar en las opciones del compilador Turbo C (o el que utilicemos) para que avise con un mensaje en todos los casos que nos ofrece.

  • Cuando creamos nuestro fichero de cabecera (.h) tenemos que tener las siguientes instrucciones en éste:

#ifndef__IDENTIFICADOR

#define__IDENTIFICADOR

(...)

#endif

Sentirse programador

miércoles, julio 12, 2006

Este escrito lo encontre en Internet, no recuerdo la fuente, pero se me hizo muy interezante, jeje

-----------------------------

Sentirse programador

Una de las cosas que más me cuesta explicar a la gente no informática con la que me relaciono es la sensación que tienes cuando oyes la llamada del código. Suele suceder cuando llevas un tiempo sin programar. Puede que durante ese tiempo hayas estado con ordenadores durante diez horas al día, navegando, administrando, leyendo... pero no programando.

Entonces un día, sin previo aviso, te entra el gusanillo. Tienes una idea o decides llevar adelante un proyecto que tenías aplazado y comienza la vorágine.

Al principio, con fiebre extrema, pasas horas aprisionado delante de la pantalla, el teclado echa humo y desarrollas líneas de código a toda velocidad. El síntoma principal es el insomnio, normalmente la fiebre te entra a primeras horas de la noche, y no vas a perder el tiempo durmiendo o cenando. Las únicas distracciones que te permites son levantarte a preparar una cafetera, ya que otro síntoma es el consumo de bebidas estimulantes. Cierras el irc, el jabber, el correo y los feeds por leer se acumulan, todo lo que te pueda distraer es eliminado y solo tienes un objetivo: el código.

La siguiente fase es la de reorganización. En un momento dado te das cuenta que tu mente va más deprisa que el código que generas, antes de entrar en esta fase es al revés, y que deberías parar un momento a generar un código más eficiente, más portable, más legible, algo más estandarizado y que incluso un subversión te vendría bien. Al final pasas del subversión por el tiempo que te llevaría leer tres páginas de documentación y sufres del clásico síntoma de libreritis. Empiezas a organizar clases en librerias, creas apis, renombras variables y desgastas dos milímetros las teclas de copiar y pegar.

La tercera fase es la del piño. Te quedas atascado con un problema, ya que al único que compilan los programas a la primera es a Chuck Norris. Un fallo que no encuentras, una situación que no te habías planteado o cualquiera de los múltiples poltergaist que se encuentra un programador. Llenas el código de printfs, de asignaciones de variables y juras en arameo. Al llegar a esta fase, si no vives solo, tu pareja percibe que no te ha visto últimamente y decide venir a empreñarte con tonterías como "¿qué haces?" o "¿qué te pasa?" justo a mitad de una sesión de debug.

Esta fase se puede prolongar en el tiempo y tu nivel de estrés sube de forma exponencial, además tu pareja también se estresa contigo diciendo que la ignoras, que la haces sentir mal y que además hay que ir al super para hacer la compra. La mayoría de divorcios de programadores son provocados por una mala asignación de valores no detectada.

Poco a poco el estrés se te va pasando, pero el interés por el programa bloqueado también, es en ese momento cuando vuelves a la vida real. Empiezas con las comidas a las horas que toca, ves algo de televisión, incluso duermes, pero... no del todo.

El problema se ha quedado incrustado en tu cerebro en segundo plano, si te concentras un poco incluso le oyes dar vueltas por ahí dentro, y precedido por un toque de trompetas aparece la solución al jodido bug. Da igual lo que estes haciendo o la hora que sea, normalmente las tres de la mañana, vas corriendo a la computadora y tienes una recaída de la fiebre inicial y entre gritos y exclamaciones varias descubres que funciona

Por último tienes el subidón, terminas el programa y la cosa funciona. Buscas gente a quien contarselo, si el programa es complejo te das cuenta de lo bueno que eres y te cuelgas medallas. Caminas por la calle con una sonrisa de oreja a oreja y cuando la gente te mira lamentas que ellos no sepan todo lo que tú has hecho, pero el subidón se pasa y vuelves al letargo. Volverá a pasar un tiempo hasta que tengas tú idea o que el proyecto te apasione y mientras tanto pasaras las horas con tu ordenador esperando, ¿deseando?, que vuelva esa sensación.

En resumen, no se si un programador es un yonki, que tiene que meterse su dosis para tener el subidón de forma periódica, o un enfermo crónico con recaídas en su enfermedad. ¿tú que piensas?

Creando un niño Linux

sábado, julio 08, 2006