J'ai une 30 de mails de retard a lire sur la ML, mais j'ai déjà des
choses à dire. Il semble que nous soyons partis pour écrire une sorte de
"norme de développement Nasgaia". Je suis complètement pour. Et
j'oserais rajouter (mais peut etre que ca a déjà été dit dans un des
mails que j'ai pas lu) que cette norm devra apparaître sur le site web
de nasgaïa, et pas au fin fond du trou du cul des archives de la ML.
Gontran a écrit :
Je commence alors ? :-)
Voici les conventions que j'utilise (enfin, presque ;-) ). Ce ne sont pas
forcément des propositions à adopter, mais à débattre. C'est juste pour faire
une liste de départ.
- Chaque fichier de code contient un entête indiquant le ou les auteurs du
code figurant dans ce fichier, la licence sous laquelle est placée ce code
(en l'occurence GPL 2 et + pour nous) et une ou deux lignes résumant le
contenu du fichier (rôle du code qui s'y trouve)
très belle entête, soit dit en passant :)
- Chaque fichier est organisé en sections dans l'ordre suivant : « includes »
généraux, variables globales au fichier, fonctions « privées » utilisées
uniquement par le code contenu dans le fichier, fonctions « publiques »
pouvant être utilisées par le code contenu dans le fichier ou situé dans
d'autres fichiers, code principal du fichier (« main »). Chacune des sections
est optionnelle, mais elles sont toujours placées dans cet ordre
- le nom des variables globales est en majuscules. Les variables globales
composées de plusieurs mots utilisent le caractère « _ » pour séparer ces
mots.
- l'utilisation d'une variable se fait en utilisant la forme « "${nom_var}" ».
Les guillemets sont optionnels dans certains cas spécifiques.
Quelqu'un peut il m'expliquer la différence précise entre "${var}"
${var} et $var ?
- le nom des fonctions « privées » commence par un « _ ». Les fonctions
« publiques » commencent par une lettre ou un chiffre. Le fait de les
distinguer permet de savoir rapidement s'il faut chercher la déclaration
d'une fonction dans le même fichier ou non.
- chaque fonction est précédée d'un commentaire indiquant son rôle, la nature
et le rôle de ses arguments, éventuellement de la valeur de retour et sa
nature, la manière dont elle est retournée (dans une variable globale ou
écrit sur stdin) et les différents codes d'erreur pouvant être retournés et
leur motif.
si on écrit sur stdin, on ne "retourne" pas, on affiche !
De manière générale, je suis à la fois pour et contre. Je suis pour
parce qu'il faut. Expliquer a quoi sers la fonction, ce qu'elle retourne
et tout le toutim, il faut. Mais bien souvent, les variables ont des
noms qui expriment ce qu'elle font (ou tout du moins, il faut qu'il en
soit ainsi), et ca fait parfois pléonasme de dire :
${PACKAGE_NAME} : contient le nom du package
Mais bon, il faut quand même le faire...
J'aime paaaaaaas la doc
- L'indentation du code ne se fait qu'avec des caractères espaces, pas des
caractères tabulations (je sais, ce n'est pas le cas dans tous les fichiers
de Ncooker, mais je suis en train de le faire au fur et à mesure que je
repasse dans chaque fichier :-) ). Une tabulation équivaut à quatre espaces.
IFS="
"
for i in `ls`
do
cat $i | expand -4 > $i.tmp
mv $i.tmp $i
done
tadaaaaaaa
Bon, évidement, il y a des fois ou il faut quand même repasser un peu
derriere à la main...
---
rougeeeeeeeeeeee
