Voici les choses que j'ai le plus souvent répétées
durant les TDs des années passées, et si je pouvais
éviter de les répéter cette année [1], cela serait un progrès
indéniable :
Il n'est pas nécessaire d'imprimer tous les énoncés
de tous les TD de système. Si vraiment vous avez envie de massacrer
des forêts norvégiennes, faites le modérément,
en imprimant en plus petit pour gâcher moins de
papier. Mieux : n'imprimez que les corrections des TD, cela vous
sera plus utile ; pour imprimer du code, utilisez a2ps.
Avant d'utiliser un appel système ou une fonction, il faut lire
sa manpage.
Les bonnes manpages sont en anglais. Si vous ne comprenez pas la
version française, essayez la version anglaise ("export
LC_ALL=en_US" peut aider).
Si vous avez du mal avec l'anglais, peut-être que l'informatique
n'était pas votre voie. Hélas, la diplomatie internationale
(voir plus loin) est aussi à exclure.
J'ai dit que les bonnes manpages étaient en anglais, mais
j'ajouterai : une bonne manpage est une manpage lue
(et même "comprise", mais n'en demandons pas trop tout de
suite).
Les manpages sont organisées en sections ; par exemple la
section 2 contient les appels système et la section 3 les fonctions
de bibliothèque. Pour obtenir la manpage de la fonction de
bibliothèque readdir() il faut faire "man 3 readdir".
C'est un cas d'école, car il existe aussi un appel
système readdir() mais personne ne veut l'utiliser, donc
c'est la manpage de la fonction que vous voulez. Retenez
ça pour le premier TD !
Dans les manpages, il y a une section "RETURN VALUE". Il
faut la lire aussi, car beaucoup de fonctions et d'appels système
ont une valeur de retour indiquant si une erreur a eu lieu. Il faut
toujours vérifier cette valeur de retour, tout comme
vous devez regarder à gauche [2] avant de
traverser l'autoroute lorsque vous êtes un hérisson (et
même si vous n'êtes pas un hérisson, mais on trouve
beaucoup de hérissons écrasés, donc un petit
conseil n'est pas de trop).
N'utilisez pas de choses compliquées là où des simples
suffisent. En particulier : n'utilisez jamais malloc(), sauf quand
il n'y a vraiment aucune autre solution (et encore). Pour certains d'entre
vous, il est important de montrer qu'on sait utiliser malloc()
et les pointeurs. En fait, mon point de vue est qu'il est important de
ne pas montrer qu'on ne sait pas utiliser
malloc().
Apprenez à utiliser make et gdb le plus rapidement
possible. Conseil pour les débutants : positionnez la variable
d'environnement CFLAGS="-g -Wall", puis pour compiler
toto.c faites simplement make toto.
Rappelez-vous toujours, avant de dire "je rajouterai le code pour tester
les erreurs plus tard", la célèbre phrase de Larry : "Ne
fais pas ça ! .... Sinon tu meurs !".
Enfin, d'autres directives seront sûrement ajoutées à
cette page au fur et à mesure de l'année, en fonction des
choses étonnantes que certains d'entre vous ne manqueront pas d'inventer.
Aussi, consultez rapidement cette page avant chaque TD - après tout,
les préliminaires ne sont pas faits que la première fois.
Quelques bonnes pratiques de programmation
Liste non exhaustive :
Ne jamais déclarer de buffer de taille arbitraire, comme
100 ou 1000. Toujours déclarer un buffer de taille
buffersize, avec un #define ou un mécanisme
équivalent.
Lorsqu'un appel système échoue, utiliser perror()
pour afficher un message d'erreur informatif.
[1] Bien sûr, je peux toujours arrêter
de les répéter ; j'aurais dû dire "si vous pouviez
écrire du code suffisamment correct pour que je n'aie pas besoin
de les répéter" ou quelque chose dans cette veine, mais je
crois que tout le monde a compris (ceux qui n'ont pas compris peuvent envisager
une carrière brillante dans la diplomatie internationale, domaine
dans lequel il est souvent nécessaire de faire comme si on n'avait
pas entendu ce qui n'a pas été dit).
[2] Il faut regarder à gauche pour la première
moitié de l'autoroute, puis, au niveau de la bande de séparation,
il faut regarder à droite. En fait, il vaut mieux regarder des deux
côtés à chaque fois, histoire de ne pas se tromper
; et puis, il peut toujours y avoir quelqu'un qui roule à contresens.
Il y aura souvent une section "private jokes" à la fin
des énoncés de TD, pour occuper les quelques élus
qui arriveraient à terminer le TD. Il est interdit de lire cette
section tant que tout le TD n'a pas été fait; ainsi, toute
personne se permettant un commentaire désobligeant sur le niveau
des private jokes en question risque de se voir poser des questions
désobligeantes comme par exemple "Alors comme ça, tu as
fini le TD? C'est bien ce que je pensais, l'énoncé est
trop court; tiens, pour la peine le prochain sera plus long et puis il
sera noté en plus, va annoncer ça à tes petits
camarades, ça va beaucoup les faire rire".
