Salut,
non non, c'est pas pour me vanter: c'est pour éviter qu'on écrase des
fichiers... Je suis en train de travailler sur la prochaine 1.1,
c'est-à-dire la messagerie interne (groupware, coco). Comme ça
devrait entraîner des modifs sur pas mal de fichier, merci de ne pas
trop intervenir sur /ecrire dans les heures qui viennent.
Tu ne voudrais pas qu'on temporise un peu ? Au moins attendre
de se réunir avec Fil pour discuter de tout ça.
Avant de se lancer dans des modifs majeures, je pense qu'on
devrait un peu 1) attendre les premiers retours du lancement
(âge : deux jours...), 2) corriger les bugs et consolider
le code.
Ca me fait chier de prêcher dans le désert, mais un code illisible et
sale, c'est la garantie que le projet soit ingérable dans quelques
temps (encore une fois, exemple : le code de l'ancienne version d'uzine :
plusieurs fois plus petit que SPIP, et pourtant imbitable car écrit à la
va-comme-je-te-pousse ; mais le code n'étant pas destiné à être
partagé, ça se comprenait). Avec les probables bugs à corriger
d'urgence amenés par le lancement, ça risque de ne pas s'améliorer,
donc vaut mieux prendre les devants.
Ce qui me gêne le plus (bien que ce ne soit pas le seul endroit,
et que mes bouts de code à moi soient aussi loin d'être parfaits),
c'est le nouveau inc-public.php3, avec la gestion des pétitions
et des inscriptions rédacteurs. Les problèmes posés sont vraiment
des problèmes de base de la lisibilité et de la propreté d'un
programme (infiniment plus basiques que l'orientation objet
présente dans certains systèmes, par exemple ; l'ensemble de SPIP,
pour des gens très à cheval, sera considéré comme une porcherie ;-)).
Je donne quelques exemples pour clarifier ; attention, ce n'est
nullement exhaustif :
- la fonction testersipage() ne respecte pas les règles de
nommage des fonctions. Depuis le début les fonctions s'écrivent
en minuscules_avec_des_underscores(). Ce n'est ni mieux ni
moins bien qu'une autre convention, simplement c'est celle
qui existe et changer de convention en plein milieu, c'est
malvenu ;))
- cette fonction a évidemment un nom idiot : on ne sait pas
de quoi ça parle (une page SPIP ?...). un nom du genre
tester_url ou tester_presence_http ou je ne sais quoi,
serait plus clair.
- le code de chargement d'une page http est maintenant
dupliqué à trois reprises : testersipage() et TesterPage()
dans l'espace public, une autre dont je ne me souviens
plus le nom dans l'espace privé. Ca fait au minimum une
de trop....
- toujours sur cette fonction, mais là je veux bien m'en
charger, la récupération du code de retour HTTP est
surréaliste : on teste simplement si le contenu
renvoyé contient la chaîne "302". Il suffit donc qu'un
autre en-tête que le code de retour HTTP contienne cette
chaîne, ou même que la page HTML elle-même contienne
cette chaîne, et l'URL est considérée comme non-valide.
Bon, ce n'est plus dans les considérations de propreté,
mais quand même : l'expérience prouve que du temporaire
mal foutu, si personne ne s'en charge rapidement, se
transforme à coup sûr en définitif mal foutu.... De
plus, copier/coller du code à partir d'une doc ou d'un
autre script sans essayer de réfléchir à la façon dont
ça fonctionne, c'est une mauvaise idée. Ca fait gagner
du temps au début, et ça en fait perdre énormément
après quand il faut réécrire parce que ce n'est pas
adapté au problème.
- toujours dans le nommage de fonction : la fonction
erreur(). Elle ne fait pas ce qu'on pense, car elle
est spécifique aux signatures de pétition. Alors il
faut l'appeler autrement : afficher_erreur_petition(),
par exemple ? En outre, elle ne semble pas très utile....
- variables globales : on l'a vu récemment ($nom_site),
les variables globales sont une ressource à utiliser
avec vigilance et parcimonie. Sinon, grosses emmerdes
en vue. Dans inc-public, il y a des variables globales
qui s'appellent $val et $compteur. Ca me semble des noms
beaucoup trop flous, susceptibles d'être utilisés pour
n'importe quoi, et donc de générer des collisions.
- récursivité : c'est une méthode de programmation
qui peut sembler élégante mais qui est extrêmement
crade quand employée à n'importe quel propos (sans
compter d'éventuels problèmes de performance, mais
sous SPIP ce n'est pas trop le cas). Au plus, la
récursivité doit être employée quand l'énoncé du
problème contient effectivement une récursivité
(par exemple "calculer les rubriques qui contiennent
au moins un article publié, et toutes les rubriques
parentes de ces rubriques, et ainsi de suite" ;
malgré cela, on a quand même pu faire une solution
non récursive, plus propre). Quand il s'agit de
"trouver un login qui n'existe pas déjà dans
la table des auteurs", il n'y a aucune récursivité
inhérente au problème. De plus, notez bien : la
récursivité permet d'exécuter un appel de fonction
avec un contexte différent de celui de la fonction
appelante. Alors, utiliser et modifier une variable
globale ($compteur) au cours des appels d'une fonction
récursive, c'est vraiment tordu. Soit l'un l'autre
(le mieux c'est ni l'un ni l'autre...), mais pas les
deux !
- répartition du code : le but est a priori d'avoir
un inc-public le plus compact et gérable possible.
Multiplier sa taille par deux ou trois en y ajoutant
directement la gestion des pétitions et des inscriptions,
c'est pas génial. Il aurait peut-être fallu un ou deux
includes supplémentaires.
Bon voilà pour quelques exemples, et ce qui est très
sympa aussi c'est de respecter les règles typographiques
à peu près reconnues (il y a des règles de typo en
programmation comme il y en a dans les différentes
langues naturelles). Principalement les espacements,
ou non, avant et après les différents caractères
(parenthèses, accolades, etc.). Et aussi les tabulations
du texte : un code indenté correctement, c'est
irremplaçable, et je vous raconte pas l'horreur quand
je suis arrivé sur le projet ;).
J'insiste encore un coup : plus la proportion de code
crade est grande, plus la complexité du projet devient
difficile à maîtriser. Au final, on se retrouve à ne plus
faire que des patches et des corrections de-ci de-là,
qui se trouvent en plus créer d'autres bugs, d'autres
problèmes, parce que ces patches et ces corrections
sont faites à l'aveugle, sans vue d'ensemble ni maîtrise
de l'architecture du code....
Donc il faudrait vraiment reporter les ajouts majeurs
(groupware), et se mettre d'accord sur les choses
exprimées ci-dessus, et d'autres améliorations dans
la structure qui me semblent intéressantes. Ensuite,
faire d'abord quelques ajouts mineurs (inclusion de
squelettes par exemple) qui permettront de tester que
ça marche.
a+
Antoine.