Re :-)
Gontran wrote:
Je commence alors ? :-)
Messieur les anglais tirez les premiers !
- 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)
100 %.
Je remet une couche en disant que tous les fichiers de code DOIVENT
contenir la license et la liste des auteurs.
Ne pas le faire exposerait le code a une copie/détournement par un tier
qui ne serait pas dans l'esprit du libre...
Pour le choix des licences je ne sais plus si on en a déjà parlé (en
fait je sais mais je reviens à la charge :-p). En ce qui me concerne je
propose qu'il soit distribué sous
Creative Commons telle qu'elle est présentée ici :
http://creativecommons.org/licenses/by-sa/2.0/fr/
Ce qui me plait c'est la clareté et l'accessibilité (par rapport à la
GPL), la robustesse de Creative Commons (que la GPL a aussi),
l'internationalisation (un réel effort est fait de ce côté, ce qui n'est
pas le cas de la GPL). De très nombreuses organisation utilisent cette
license. Pour n'en citer que quelques unes : Linuxfrench, framasoft
(article intéressant :http://www.framasoft.net/article2185.html), l'AFUL
etc... Ce qui témoigne du sérieux et de l'intérêt que porte la
communauté du libre à cette license...
Dans tous les cas, quelque soit la license qu'on utilise il est de bon
gout de n'utiliser que des bouts de code libre (au cas où on doit en
emprunter chez les autres) et de prévenir leur développeur (en
particulier Martial, surtout si on change de license...)
- 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
Entièrement d'accord.
J'ajouterai : les sections sont délimités par des entêtes explicites du
style (à définir) :
###########################################
#### INCLUDES
####
###########################################
- 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.
100 % Ok
- l'utilisation d'une variable se fait en utilisant la forme « "${nom_var}" ».
Les guillemets sont optionnels dans certains cas spécifiques.
100% Ok. Question : les guillemets sont bien pour éviter les
désagréments avec les espaces dans les noms de paquets/chemins, c ça ?
Les cas particuliers sont pour le passage d'arguments multiples à une
fonction c ça ?
- le nom des fonctions « privées » commence par un « _ ».
100 % d'accord
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.
Pas d'accord pour qu'un nom de fonction commence par un chiffre (surtout
si elle est "publique"). Pour moi le fait qu'une fonction commence
par un chiffre rend le code peu lisible. Je dirais que le nom du
fonction devrait commencer par une lettre, amha.
- 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.
100 % Ok
- 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.
MDR !!! Gontran tu pensais faire passer ça sans que je le vois !!!! (on
a eu un petit débat ensemble sur TAB ou ESPACE pour l'indentation...).
Qu'est-ce qui t'a fait changer d'avis ?
Dans tous les cas je suis d'accord :-)
- Indentation pour if :
if <condition>; then
<code si condition vraie>
elif <condition; then
<code si condition vraie>
else
<code si condition vraie>
fi
- indentation pour for :
for <var> in <list>; do
<code>
done
for (( ... ; ... ; ... )); do
<code>
done
- indentation pour while :
while <condition>; do
<code>
done
- indentation pour until :
until <condition>; do
<code>
done
- indentation pour case (les caractères « ) » de chaque ligne <case*> sont
alignés) :
case <var> in
<case1> ) <code>;;
<case2> )
<code>
;;
esac
- indentation pour une déclaration du fonction :
<name> () {
<code>
}
A noter l'indentation "java like" pour les accolades :
toto () {
}
au lieu de l'indentation "C" classique :
toto ()
{
}
Perso je suis pour l'indentation "java like", depuis que je l'ai
découverte je ne peux plus m'en passer. Maintenant je comprends que ça
puisse
gêner plusieurs d'entre nous. Peut importe le choix qu'on fait. Ce qui
est important c'est qu'on utilise tous le même partout.
Quoi d'autre :-) ? ...
Un truc que je n'ai pas utilisé pour Ncooker, mais que j'utilise lorsque je
développe en PHP, c'est d'indiquer dans le nom d'une variable son type et sa
portée. Je sais parfaitement que les variables ne sont pas typées, mais
généralement, chaque variable possède une valeur d'un type bien déterminée
tout au long de son existence. J'utilise cette convention :
Portée :
g = globale
l = locale
Type :
a = array
i = integer (ou plutôt un nombre de manière générale)
s = string
m = mixte (la variable contient des valeurs de types différents tout au long
de son existence)
Le format des noms de variables est le suivant :
<portée>_<type(s)><nom>
Par exemple :
« g_sName » est une variable globale contenant une chaîne de caractères
« l_iCount » est une variable locale à une fonction contenant un nombre
« g_asURLs » est un tableau global de strings
« l_mValue » est une variable locale pouvant contenir soit un nombre, soit des
caractères
etc ...
grâce à cette notation, je repère très rapidement la portée et le type d'une
variable dans mon code sans avoir à chercher sa déclaration ou à rechercher
dans le code le type de valeur qui lui est affecté.
Pour les fonctions qui retourne une valeuur, j'indique également le type pour
la valeur de retour dans le nom :
iGetValue() retourne ainsi un nombre
sGetURL() retourne une chaîne
Je suis entièrement d'accord avec tous ça.
Je rajoute que tes "coding rules" sont utilisées par de très nombreux
développeurs dans le monde (au sein de la communauté et dans les
entreprises, pour ce que j'en ai vu). C'est aussi important pour tous
ceux qui voudraient nous rejoindre ou utiliser notre code.
Merci Gontran pour avoir mis tout ça en forme :-)
++
Chicha.
