oui, il y a eu une legere derive
donc pour recentrer le "debat" :



toujours penser aux classes d'une appli comme une arborescence avec des groupes et sous-groupes (dans le cas d'une grosse appli) ayant un but commun.
ex : un sous-groupe qui contient tous les classes de gestion des differentes bases de données (MySQL/SQL/...) ; une autre pour la gestion des connexions externes (Socket/Ftp/...) ... etc



toujours documenter son code en s'aidant des regles de PHPdocumentor ce qui fait une appli ou un package de classes qui est + facilement maintenable pour une personne externe.



pour le nommage des variables, j'utilise un technique perso que j'applique a tous les languages meme a ceux n'ayant pas de typage strict comme le JS ou PHP, elle me permet de savoir automatiquement ce que contient une variable .

ex pour le type des vars en PHP :
stVar (chaine)
nbVar (nombre)
tbVar (tableau)
rsVar (ressource)
.... etc

ex pour le Pascal, le C ou autre languages a typage strict :
stVar (chaine)
itVar (entier)
flVar (nombre decimal)
tbVar (tableau)
obVar (object)
.... etc



pour le nommage des classes/vars membres et methodes :

Class Mysql{ (majuscule pour un nom de classe)
stLoginMy = '' (st pour chaine / My pour indiquer la classe mere)


function myConnec(){ (my indique la classe mere)
}
}

evidemment ce systeme est a adapter suivant le besoin d'heritage



mis a part ca, je ne suis pas de ceux qui utilise des _ pour separer les mots d'un nom de var/fonction/methode, je prefere les majuscules comme separateur, ex :
getService() plutot que get_service()
$stLogPseudoFtp plutot que $st_log_pseudo_ftp
mais ce point est surement discutable, disons que ca doit dependre des gouts de chacun.

moi je suis de ceux qui pensent que la documentation est une bonne chose
au contraire de documentaire balancer sauvagement dans le code

le code fait partie de la documentation, il doit donc est clair, et explicite
je pense que le typage d'une variable de retour est une bonne chose, ca peremet de voir rapidement quel genre retourne la fonction
ex: return (array) $reslut;

sinon le best practice repond largement a ce sujet(enfin je crois)

en termes d'optimisations, je suis pour les optimisation développeur vs optimisations machine. en gros je prefere une architecture carrée, sans exception, avec une classe pour la connexion à un espace membre, même si cette classe est "pipeau" et ne contient que 2-3 choses.

Pour la doc, j'en mets un peu dans le code, et je me force à avoir un entete dans chaque fichier; j'utilise un wiki pour détailler un peu plus.

La doc c'est un sujet sensible avec une collegue: elle ne documente pas le code, même pas d'entete, sur des fichiers dont le nom n'est même pas parlant; et elle ecrit sous word, quand elle a le temps, mais laisse tout ça sur son ordi: "je peux pas la filer, la doc est pas finie"; sauf qu'elle ne sera jamais finie cette doc...

c'est aussi pour ça que j'aime la facilité du wiki.

A+

Pascal

Salut,

Pour ma part, niveau doc, j'essaie d'en mettre le plus possible dans le code biensur et pas question de faire une doc
"à côté" comme le font certains ce qui n'est pas une mauvaise idée non plus mais faut du temps.
Niveau écriture du code, j'opte maintenant pour le style Pear qui me satisfait très bien, c'est parfaitement clair et lisible,
même chose pour la documentation des classes, méthodes, etc...
D'ailleurs phpDocumentor est très bien pour ça.

@+