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.

@+

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

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)

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 :
[b]st[/b]Var (chaine)
[b]nb[/b]Var (nombre)
[b]tb[/b]Var (tableau)
[b]rs[/b]Var (ressource)
.... etc

ex pour le Pascal, le C ou autre languages a typage strict :
[b]st[/b]Var (chaine)
[b]it[/b]Var (entier)
[b]fl[/b]Var (nombre decimal)
[b]tb[/b]Var (tableau)
[b]ob[/b]Var (object)
.... etc



pour le nommage des classes/vars membres et methodes :

Class [b]M[/b]ysql{ (majuscule pour un nom de classe)
[b][color=blue]st[/color][/b]Login[b][color=red]My[/color][/b] = '' ([color=blue]st pour chaine[/color] / [color=red]My pour indiquer la classe mere[/color])


function [b]my[/b]Connec(){ (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 :
[i]getService()[/i] plutot que [i]get_service()[/i]
[i]$stLogPseudoFtp[/i] plutot que [i]$st_log_pseudo_ftp[/i]
mais ce point est surement discutable, disons que ca doit dependre des gouts de chacun.

[quote]A mon avis donc, un vrai code maintenable, ça passe donc par une structuration de son code (fichiers séparés suivant le contenu, fonctions, POO...) plutôt que par des petits gadgets de ce genre.[/quote]

tout a fait d'accords,
il est vrai q'une certaine rigueur dans le code permet d'ameliorer la lisibilité
mais le point essentiel reste l'architecture et les regles de nommages
il suffit de bien découper les taches que ce soit avec un MVC ou un systeme plus simple(2 -couches)

while (true == false) {
?>
<option>
<?php
}
?>

Ahah, quand j'ai vu le sujet posté, j'attendais avec impatience le débat :lol:
C'est dommage, ça aurait pu devenir un vrai recueil des bonnes habitudes à avoir, mais ça a dérivé.

Vous avez passé beaucoup de temps à parler de l'indentation : des tas d'éditeurs permettent de reformater le code proprement, suivant ses envies (ex : Eclipse)
Donc bon, l'indentation c'est pas le plus important, c'est surtout important pour soit, pour avoir où on en est quand on code à mon avis

Et ce genre de trucs :
[php]
while (true == false) {
?>
<option>
<?php
}
?>
[/php]
beaucoup, dont moi, trouvent ça complètement illisible, tout ça pour gagner quelques millièmes

A mon avis donc, un vrai code maintenable, ça passe donc par une structuration de son code (fichiers séparés suivant le contenu, fonctions, POO...) plutôt que par des petits gadgets de ce genre. ;)

Pour ma part j'ai opté pour un mini moteur de template que j'utilises et que j'améliore au fur et à mesure, cela me permet de me concentrer uniquement sur la programmation, laissant le soin au designer de faire sa part de travail sans se soucier d'implenter du code php incompréhensible pour lui (ou eux).
Les possiblités sont infinies; inclusion à la volé de portion de fichier html, changement en cascade, boucle, condition, et cela avec un code allégé et ultra simplifié, par exemple:
[code]{dowhile:VALEUR}
<tr>
<td>{VALEUR}</td>
</tr>
{dowhile:end}[/code]
la valeur assigné à VALEUR (un tableau) sera lu jusqu'à la fin de ce dit tableau.
Ou bien [code]{include:fichier.tpl:tag}[/code] incluera la portion définie entre 'tag' du fichier fichier.tpl.

C'est une solution que je trouve, en ce qui me concerne, pratique; gain de temps de développement, le code html n'est plus ambriqué entre "" et les antislashs aux oubliettes...

Voilà, voilà.
Néanmoins, pour un projet de moindre envergure, la mixité est possible.

Low

Si tu cliques sur un champ du premier formulaire, il se vide. Si tu quittes ce champ sans l'avoir modifié il se remplit à nouveau avec sa valeur d'origine (sauf dans le cas du mot de passe, pour éviter les confusions).

Le second formulaire n'a aucun comportement associé.

Note : pour getElementsByClassName j'ai l'habitude de l'implémenter ainsi [code]Node.prototype.getElementsByClassName = function (sel) {
sel = sel.toUpperCase();
var selArray = sel.split(".");
if (selArray.length > 1)
return this._getElementsByClassName(selArray[1], selArray[0]);
else
return this._getElementsByClassName(sel);
}
Node.prototype._getElementsByClassName = function (cls,tag) {
var res = new Array();
for (var i=0; i<this.childNodes.length; i++) {
var node = this.childNodes[i];
if ( (" "+node.className.toUpperCase()+" ").match(cls) && (!tag || node.tagName.toUpperCase() == tag) )
res.push(this.childNodes[i]);
res = res.concat(this.childNodes[i]._getElementsByClassName(className));
}
return res;
}[/code]

Ainsi tout élément de la classe Node (ce qui inclut bien sûr document) gagne une méthode "getElementsByClassName" à qui on peut passer simplement un nom de classe, ou bien un sélecteur de la forme "TAG.CLASSE" pour filtrer également par tagName.
Par exemple document.getElementsByClassName("ul.menu").

J'aime beaucoup ton truc naholyr, c'est ce genre de choses que je voulais voir apparaître dans cette discussion : les trucs de chacun.
Je vais me pencher sur ta solution et la tester un peu.

Par contre sur ta page d'exemple, quelle est la différence entre les deux formulaires ?

[quote="Hermès"][quote]c'est vrai qu'il est plus "propre" de différencier les balises qu'on doit "javascripter" et de leur rajouter des gestionnaires d'évenements[/quote]

En parlant de ça, n'est-il pas possible d'intégrer du javascript via du CSS ?
Bon ok, c'est plus vraiment du CSS dans ce cas là, mais l'objectif aurait le même résultat : supprimer tous les attributs de la balise html pour les intégrer dans le fichier "CSS" grâce à leur classe ou leur ID.
Ca serait l'idéal pour alléger le code en terme de lisibilité (bon, par contre, ça faciliterait pas la compréhension du code si le javascript fait des trucs délicats).[/quote]MERCI !!!
À moi aussi ça me parait absolument naturel d'avoir une syntaxe "css-style" pour indiquer les comportements.
Par exemple on pourrait avoir [code]a.popup {
onclick : { window.open(this.href); return false; }
}[/code]

Et ben ça existe : ça s'appelle les "behaviours" (comportements). J'ai pris une librairie qui faisait ça très bien mais uniquement sur les id et classes, j'ai pris une librairie qui parsait très bien le css (qui demandait 2-3 corrections, et à laquelle j'ai ajouté la gestion des expressions régulières dans les valeurs d'attribut, ce qui n'existe pas en css mais qui est bien sympa), j'ai mixé les deux, et ça marche très bien :)

http://naholyr.free.fr/labo/behaviour/
Dans cette page d'exemple il n'y a pas une once de javascript dans la page elle-même, il n'y a que la déclaration des comportements au début de la page (avec des Behaviour.register comme ci-dessous). L'idéal pour faire du javascript non-intrusif.

La syntaxe exacte pour l'exemple du a.popup serait [code]Behaviour.register({
'a.popup' : function(a) {
a.onclick = function() {
window.open(a.href);
return false;
};
}
});[/code]

Je pense que c'est une mauvais idée de gérer le CSS avec du JS tout simplement parce que tu ne vois pas quel est le style de ta page tant qu'elle n'est pas générée.

Je ne pense pas que mettre des classes dans le code HTML allourdisse vraiement le code. Au contraire, ça permet de s'y retrouver un peu.

Sinon, un eventHandler, c'est un écouteur d'événement.

Au chargement de la page, tu dit à JS "Dès qu'un clic/survol/... sur une balise TD ... dès qu'un clic/survol/... sur un id untel"

C'est comme si tu faisais un onClick/onMouseOver/... sur toutes les balises TD, sur les id untel, mais généré au chargement de la page et sans alourdir le code.

Mais c'est plus compliqué à coder ;)

euh, mettre du code javascript directement dans le css je ne pense pas que ce soit possible... encore heureux, mes feuillles de style sont les seules choses propres de mes sites :lol:
Par contre voici le principe pour "faire comme si" (j'ai plus le code sous la main, mais j'avais utilisé quelque chose comme ça...):
tu parcours tous les tags de ton document et quand le tag a une classe particulière tu lui appliques un gestionnaire d'évenements ou n'importe quoi d'autre
C'est propre mais c'est lourd : le top serait d'avoir une fonction getElementByClassName similaire à l'actuelle getElementByTagName, mais libre à toi de l'implémenter ;)

Edit : Les eventHandler sont littéralement des "gestionnaires d'évenements", c'est à dire onclick, onmouseover, onfocus...

C'est quoi que vous appelez les eventHandlers ?

Un code propre et portable, selon moi, est un code où chaque langage est séparé proprement. Donc, effectivement, je suis partisant de créer des fonctions JS et des eventHandlers pour diminuer l'imbrication HTML/JS

[quote]c'est vrai qu'il est plus "propre" de différencier les balises qu'on doit "javascripter" et de leur rajouter des gestionnaires d'évenements[/quote]

En parlant de ça, n'est-il pas possible d'intégrer du javascript via du CSS ?
Bon ok, c'est plus vraiment du CSS dans ce cas là, mais l'objectif aurait le même résultat : supprimer tous les attributs de la balise html pour les intégrer dans le fichier "CSS" grâce à leur classe ou leur ID.
Ca serait l'idéal pour alléger le code en terme de lisibilité (bon, par contre, ça faciliterait pas la compréhension du code si le javascript fait des trucs délicats).