REGLAS DE ORO DE LA PROGRAMACISN

1.- El programador debe siempre tener en cuenta que el usuario siempre se hace el inztil (a veces, ademas, lo es).

2.- El usuario nunca se lee las ayudas on line.

3.- El programa debe incluir ayuda on line para que el programador se las lea al usuario cuando este lo necesite.

4.- El usuario nunca sabe lo que quiere hasta que ve lo que le dan.

5.- El usuario y el programador siempre hablan distinto idioma.

6.- Hacer un programa es facil. Lo difmcil es que funcione correctamente.

7.- Modificar un programa es facil. Lo difmcil es modificarlo correctamente.

8.- Detectar fallos en un programa es facil. Lo difmcil es detectarlos todos.

9.- Para que un programa funcione correctamente, no basta con que lo haga 1 vez.

10.- Para que un programa funcione correctamente, no basta con que lo haga 100.000 veces.

11.- Primer enunciado de la Ley Universal de la Programacisn: Todo programa siempre es posible mejorarlo -liase tambiin ampliarlo/corregirlo-.

12.- Segundo enunciado de la Ley Universal de la Programacisn: Un programa no se termina nunca (y cuando se esta programandolo, parece interminable).

13.- Las Normas de Estilo deben cumplirse durante la programacisn, y no al terminar el programa, en la revisisn final.

14.- Si un programa no esta bien intentado, no es programa sino jeroglmfico.

15.- Lo mas difmcil de un programa es elegir los nombres de los indicadores (constantes, variables, funciones, procedimientos y tipos de datos), para que estos sean mas significativos.

16.- Usar identificadores no significativos ayuda a aumentar la complejidad de nuestro jeroglmfico.

17.- Usar constantes a pelo en nuestro programa (sin asociarlas a identificadores #define...), ayuda a aumentar la complejidad de nuestro jeroglmfico.

18.- Nuestro programa debe incluir suficientes comentarios.

19.- if (numero_comentarios != suficiente)

GOTO Regla_anterior;

20.- (La sentencia GOTO no debe aparecer en un programa!

21.- Un jeroglmfico NO debe estar bien estructurado y modularizado. Debe contener todo en la funcisn principal, sin que existan otras funciones (procedimientos) que puedan clarificar el programa.

22.- Poner a varios programadores a trabajar sobre el mismo programa no les convierte en un equipo.

23.- En un equipo de 2 programadores, siempre ocurre alguna de las siguientes situaciones:

- Uno lo hace todo y el otro sslo pone su nombre.

- Ambos lo hacen todo y obtienen 2 programas distintos, imposible de unificarlos.

- Deciden separarse por problemas de entendimiento y al final el programa no se termina.

24.- Ley de Brooks: Meter mas gente en un proyecto de software retrasado, lo retrasa azn mas.

25.- No existe relacisn entre el tamaqo del error y los problemas que causa.

26.- La documentacisn es el aceite de ricino de los programadores. Los jefes suponen que si tanto la odian los programadores, algo tendra de bueno.

27.- Una vez comprobado concienzudamente que todo funciona correctamente y todo esta bien integrado, azn quedan al menos cuatro meses mas de trabajo para que lo comprobado sea casi-cierto.

28.- La generacisn de nzmeros aleatorios es demasiado importante para abandonarla al azar.

29.- Para descubrir los fallos de un programa probado exhaustivamente, hay que darselo a probar al usuario mas novato.

30.- La torpeza del usuario es directamente proporcional a nzmero de fallos que descubre en nuestro programa.

31.- Los fallos del programa atraen al usuario mas intensamente si es antes de pagar al programador.

32.- Si un programa no funciona, seguramente es que necesitas un ordenador unas 100.000 pts. mas potente.

33.- La programacisn sirve para solucionar problemas, no para crearlos... bueno... esta mejor la quito.

33.- Aunque suene paradsjico, la programacisn NO tiene, ni debe tener Reglas de Oro.

Apindice B del libro AEjercicios resueltos de programacisn C@, por:

Pedro J. Sanchez Sanchez

Josi Galindo Gsmez

Ignacio Torias Gsmez

Isidoro Lloret Galiano

Servicio de publicaciones de la Universidad de Cadiz.