Conseils de programmation
[le guide du mieux-programmeur(euse)]

Contenu

1. Avant-propos
2. Ce qu'il vaut mieux savoir
3. Comment résoudre l'exercice 4 de la série...
4. Quelques recommendations pour l'écriture du code

Avant-propos

Je vous recommande également de lire la rubrique « Comment résoudre l'exercice 4 de la série...»  écrite par un de mes chers confrères assistants.

Attention ! C'est un peu long et fatiguant à lire sur un écran, donc je vous conseille d'imprimer cette page, ou du moins de lire en priorité les paragraphes marqués d'un «  »

Si besoin est, écrivez-moi un e-mail, je me ferais un plaisir de vous répondre... ...en tout cas avant Pâques !

Ce qu'il vaut mieux savoir sur l'ordinateur

1. Un ordinateur est obtus

   On peut se convaincre aisément de cette affirmation en se rappelant qu'un ordinateur est un automate programmable, comme vous la dit le Prof. Chappelier dans son cours.
   C'est-à-dire qu'il ne va comprendre ou faire que ce qu'on lui a dit de comprendre ou de faire, ni plus ni moins. C'est pas gagné, mais on va lui expliquer lentement et clairement, histoire qu'il comprenne.

   Pour la programmation, cela signifie que même si vous trouvez que remplacer les points virgules à la fin de chaque instruction par des W majuscules est la plus importante innovation artistique depuis le cubisme, l'ordinateur risque malgré lui d'étouffer dans l'oeuf votre immense potentiel créatif.

   Respectez toujours la syntaxe au signe et à la lettre près quand vous programmez. Il suffit d'un espace en trop, ou d'un « n » à la place du « m » dans « main » par exemple, pour qu'il y ait une erreur à la compilation. Beaucoup d'erreurs sont de ce type lorsqu'on débute en programmation et qu'on ne connaît pas encore bien « l'orthographe » du langage.

2. Un ordinateur est profondément obtus

   C'est-à-dire qu'il ne se corrige pas (le vilain).
   Afin d'éviter de le corriger vous-même à coup de hache, sachez être magnanime envers moins ouvert que vous, et démontrez ainsi la supériorité de l'Humain sur la machine.

   En programmation, une erreur est invariante par rapport aux translations dans le temps et [habituellement] dans l'espace.
   Ce qui signifie que si deux messages d'erreurs donnés par le compilateur sont identiques, alors les erreurs le sont aussi (la plupart du temps), quel que soit le référentiel considéré.
   Autrement dit : l'espace des erreurs est isotrope et homogène (c.f. Mécanique Générale, Gruber et Benoît, p. 661)

   On refait souvent les mêmes erreurs. Essayez de regarder à quoi correspondent les messages d'erreur que vous obtenez fréquemment ; vous pourrez ainsi identifier immédiatement certaines bourdes récurrentes.

3. Un ordinateur est sournois et vicieux

   Ceci ne veut pas dire qu'une caméra numérique se trouve sous chaque chaise dans la salle d'info (quoique c'est une idée à creuser ?).
   Résumons : vous êtes en face d'un adversaire froid, insensible et capable de résoudre une équation aux dérivées partielles alors que vous téléchargez avidement le dernier mp3 de Britney Spears (non ce n'est pas du vécu).

   Si je vous dis qu'en plus, il se joue de vous avec une facilité déconcertante, là vous ressortez la hache à deux mains et un lance-roquettes avec. Mais le/la Sage sait déjouer les vils pièges tendus par la machine rusée et malveillante.

   Parfois, certaines erreurs ne sont pas ce qu'on croit qu'elles sont (what is the Matrix?).
   La réalité transcende la fiction et cette fichue compilation ne veut toujours pas se faire, pourtant je regarde à la bonne ligne, je connais le message d'erreur et j'ai beau scruter avec mes bésicles en argent du 19^e siècle, je n'y vois écrit qu'une ligne de code à première vue parfaitement juste. C'est grave docteur ?
   Non ! Deux cas peuvent se présenter :
   

   • Ça fait deux heures que vous programmez et que vous regardez votre écran : la fatigue, la lassitude et l'ennui sont là => vous ne distinguez plus la faute.
     
   • En vertu des postulats 1) et 2), le compilateur va parfois vous signaler une erreur à une ligne X, alors que le vrai problème se situe à la ligne précédente, voir même avant. C'est assez embêtant, mais avec de l'entraînement, on arrive à s'en sortir.
     

Quand vous ne trouvez pas d'où vient l'erreur, demandez à votre voisin de regarder à votre place. Un autre regard sur votre problème peut parfois faire des miracles. Et comme on [=les assistants] vient de finir notre bière de tout à l'heure de répondre aux questions d'un autre étudiant, on peut aussi venir y mettre notre grain de sel. Regardez la ligne qui précède celle où le compilateur a détecté l'erreur et vérifiez s'il ne manque pas un point-virgule, une parenthèse, un crochet ou autre chose d'anormal. Si vous ne trouvez rien, remontez plus haut, etc. Servez-vous également de l'indentation et de la mise en évidence syntaxique d'(X)Emacs pour détecter le problème. Essayer de comprendre ce que le compilateur vous dit, en vous aidant au besoin de votre voisin, ou d'un assistant (s'il en reste un pas trop assoifé surchargé).

On signalera aussi que certaines erreurs dépendent les unes des autres. Certaines d'entres elles peuvent d'ailleurs en entraîner toute une cascade : quand vous oubliez ou quand vous faîtes une erreur dans la syntaxe de la déclaration des bibliothèques au début du programme par exemple.
Si la bibliobliothèque est mal déclarée (i.e. mal inclue) -> le compilateur ne la trouve pas -> quand ensuite, il rencontre des commandes définies dans la biblio et utilisées dans votre programme, il ne les comprend pas, car elles n'ont pas été définies dans votre programme, et, en vertu du postulat 1), il ne sait pas où les chercher.

Exemple : l'oubli de «#include <iostream>» dans le programme entraînera une erreur sur quasiment chaque appel à cin, cout, endl, ...

Comment résoudre l'exercice 4 de la série 3...

Rappel de l'énoncé :

Écrivez un programme age.cc qui : demande son âge à l'utilisateur ; lit la réponse de l'utilisateur et l'enregistre dans une variable age de type entier ; calcule l'année de naissance (à un an près) de l'utilisateur et l'enregistre dans la variable annee de type entier ; affiche l'année de naissance ainsi calculée. Compilez et exécutez votre programme.

1. Squelette de base

   Commencez systématiquement votre programme en écrivant le squelette suivant : #include <iostream> using namespace std; int main() { } Naturellement, si votre programme ne comporte pas d'entrées/sorties (ce qui est rare pour un programme, mais arrive fréquemment en compilation séparée), il n'est pas nécessaire d'include <iostream>.
   Par ailleurs, si vous savez déjà que vous devrez utiliser des fonctions de la bibliothèque mathématique, des chaînes de caractères, des vectors, etc. vous pouvez également préciser les autres bibliothèques dont vous aurez besoin (<cmath>, <string>, <vector>, ...).
   

2. Déterminer les variables

   Essayer de comprendre le but de l'exercice : quel(s) calcul(s) le programme doit-il faire, quelles sont les variables du problème ?

   Par exemple, dans le cas de l'exercice considéré, l'énoncé stipule :
   

   • « lit la réponse de l'utilisateur et l'enregistre dans une variable age de type entier »
       il faut donc une variable, de type entier, appellée age.
     
   • « calcule l'année de naissance (à un an près) de l'utilisateur et l'enregistre dans la variable annee de type entier »
       il faut donc une (seconde) variable de type entier, appellée annee.
     

Remarque :

Comme il n'y a pas de valeurs initiales pertinentes pour ces variables, (c'est l'utilisateur qui, lors du fonctionement du programme, précisera ce qui peut tenir lieu de valeurs initiales), et qu'il n'y a pas de raison d'utiliser ces variables avant leur première affectation, il n'est pas obligatoire de les initialiser lors de la déclaration (bien que cela soit tout de même conseillé).

double f(const int x);

double g(const int x)
{
    double h0(f(x)), h1(0);
    double v0;

    if ( f(x) >= 0 ) {
        h1 = sqrt(f(x));
        do {
            ...
            ...
        } while ( h1 > h0 );
    }
    return v0;
}

double f (const
int x); double
g(const int x) { double h0(f(x)),h1(0); double v0;
    if (f(x)>=0){h1=sqrt(f(x));do{ ...
 ... } while (h1>h0);}return v0;}

void rebond(double& h, double& v, const double esp, const double g = 9.81);
  //
  // Simule un (et un seul) rebond de balle.
  //
  //   Entrées:  h   = la hauteur de la balle avant le rebond
  //             v   = la vitesse de la balle avant le rebond
  //             eps = le coefficient de rebond balle/sol
  //      [opt]  g   = la valeur de la gravité
  //
  //   Retour: -
  //
  //   Sorties:  h   = la hauteur après rebond
  //             v   = la vitesse après rebond
  // Retour:
  //        -
  // V.Globale:
  //        g

...

void rebond(double& h, double& v, const double esp, const double g)
{
    // le rebond est simulé à l'aide de ...
    // avec v[sol]^2 = (2hg) et ...

	double g2(g*g);    // carré de la gravité (acc. calculs)
	double f(eps*v*v); // coeff. de frottement balle-air
	double a(0);       // accélération de la particule

	...
}

---

[merci aux assistants, à l'origine de ces informations]
Dernière mise à jour : $Date: 2009-09-11 17:10:52 +0200 (Fri, 11 Sep 2009) $   ($Revision: 25 $)