Bonchour !

et meilleurs voeux !

Bon, vu avec Cyrano en privé, je lui ai parlé de l'un de mes actuels projets.

Il traîne sur internet une charte de développement en C++. Elle est très bien écrite (je vous fournis le lien en fin de message) et je souhaite l'adapter en PHP.

Malgré tout, je vais avoir besoin de vos idées : J'ai déjà fait beaucoup d'adaptations, mais je ne peux pas penser à tout. J'ai conservé beaucoup d'informations de la charte en c++ (de la copie de données, donc), et j'en ai créé de nouvelles.

Je serais donc intéressé par vos idées, tout ce que je pourrais rajouter dans la charte, mes erreurs à corriger.

Voici les documents :

c++ coding guide (timothée royer)
http://www.jalix.org/ressources/program ... ideC++.pdf

php coding guide (moi, donc)
http://www.lavisducitoyen.com/php_coding_guide.pdf

C'est le second, qu'il faut améliorer (il n'est de toute manière pas fini)

Salut,

après avoir lu le document en diagonale, j'ai remarqué plusieurs trucs que je te livre à chaud :
- le fichier index : il s'agit de l'entrée du programme en C/C++, c'est totalement différent en PHP. J'irais même plus loin en disant que je ne trouve pas très pratique d'avoir un immense fichier index.php qui sert de carrefour pour décider de la page à afficher
- les commentaire : tu utilises la suite de caractères "~*~*~*" dans tout tes commentaires. Outre le fait de la beauté, je trouve que ça charge beaucoup avec des caractères difficiles à taper. De même, pour moi, pas besoin de 80 caractère pour rendre visible un commentaire, au contraire. Personnellement, je préfères des choses comme ça

//####### Mon commentaire #######

//***** Mon commentaire *****

- Dans les divers exemples de code, il y a des sauts de lignes entre chaque ligne et ça peut être pris comme des vrais sauts de lignes
- La liste des inclusions (page 8) est beaucoup trop longues avec autant de commentaires. De plus, les majuscules sont plus difficiles à lire et j'aurais regroupé les classes entre elles. De cette manière :

//----------
//-- Inclusion des fichiers
//----------
//-- Classes --
require_once("includes/myException.class.php"); 		//Classe MyException
require_once("includes/sql/myConnexion.class.php"); 	//Classe MyConnexion
require_once("includes/template.class.php"); 		   //Classe Template

//-- Parametres --
require_once("params/php_params.php"); 			     //Parametes de PHP
require_once("params/appli_params.php"); 		       //Parametres de l'application

//-- Autres -- 
require_once("includes/secure.php"); 				   //Gestion des sessions
require_once("templates/tpl_head.php"); 			    //Fichiers de templates
require_once("plugins/pluginBegin.tpl.php"); 		   //Index des plugins
//----------

- le fichier index : il s'agit de l'entrée du programme en C/C++, c'est totalement différent en PHP. J'irais même plus loin en disant que je ne trouve pas très pratique d'avoir un immense fichier index.php qui sert de carrefour pour décider de la page à afficher

Pour autant, je ne vois pas de meilleure solution que celle ci. A vrai dire, la construction de mon fichier index est des plus simple, elle oriente tout de suite le développeur, supprime toute forme de code html ... Je veux bien quelques précisions à cet égard.

- les commentaire : tu utilises la suite de caractères "~*~*~*" dans tout tes commentaires. Outre le fait de la beauté, je trouve que ça charge beaucoup avec des caractères difficiles à taper. De même, pour moi, pas besoin de 80 caractère pour rendre visible un commentaire, au contraire. Personnellement, je préfères des choses comme ça

//####### Mon commentaire #######

//***** Mon commentaire *****

Les caractères, je peux effectivement les changer. Jusqu'à présent, effectivement, je copiais les lignes de commentaires. Par contre, le fait de les limiter à 80 caractères, c'est clairement voulu. 80 caractères, c'est pile la largeur d'impression sur une page, du coup, quand on commente les lignes, ça devient un réflexe de pratiquer ainsi. Les commentaires sont uniformes, également.

- Dans les divers exemples de code, il y a des sauts de lignes entre chaque ligne et ça peut être pris comme des vrais sauts de lignes

Je corrige de suite

- La liste des inclusions (page 8) est beaucoup trop longues avec autant de commentaires. De plus, les majuscules sont plus difficiles à lire et j'aurais regroupé les classes entre elles.

Ca n'est pas une mauvaise idée, effectivement, de regrouper. Généralement, je fais attention à l'ordre de mes inclusions. Il faut vérifier que le changer et grouper ne pose pas de problème, auquel cas je suis pour.

Ca va se construire doucement, ce livret.

Chalut !

Et meilleurs vieux aussi.

Premier message sur ce forum, et je vais commencer à me faire des amis...

1) balises :
balises d'ouverture <?php... entierement d'accord, j'apporterai juste une précision sur le fait que les balises <? simples impliquent une option de configuration facultative du php.ini (enable_short_tags si mes souvenirs sont bons) et qui dit facultatif dit pas obligatoire

2) accolades :
pas d'accord sur la présentation des accolades : je préfere la maniere de penser décrite dans thinking in java qui s'adapte tres bien à php : une ligne contient toujours une et une seule balise de fermeture. soit un ";" ,une accolade d'ouverture de bloc ( pas partisan des : .... endXXX; ) ou une accolade de fermeture de bloc qui elle, logiquement, est la seule instruction de sa ligne.

3) variables :
petit ajout. les tableaux décrivent ce qu'ils contiennent et prennent un "s"... soit un tableau qui contient des description de livres par exemple s'appelera $livres... et étant logique, on reconnait ensuite tout de suite un tableau parce-qu'il finit par un "s".
en ce qui concerne les $_ : cela peut etre pratique en php4 pour spécifier (meme si c'est pas reconnu par le langage) qu'une variable ou une méthode est sensée etre "private" (ça c'est piqué à ruby ou python je sais plus)

4) fonctions / classes :
on intervertit les regles ( une classe commence toujours par une majuscule, une fonction, jamais ).

5) exceptions :
les exceptions sont des commutateurs, pas des rapports d'erreur. pour le debugage je prefere utiliser trigger_error(). Ca a en plus l'avantage d'etre compatible php4.

6) quelques trucs pratiques pour le nommages de fonctions : is/has
isValid(), hasElement() sont des fonctions qui se comprennent au premier coup d'oeil par exemple.

7) operateur ternaire : (condition) ? true : false;
pratique mais à réserver à des expressions simples (certains diront à ne pas utiliser du tout, c'est selon)

8) précision idiote en ce qui concerne tout (arf oui c'est con comme phrase )
tous les noms ( variables, constantes, fonctions ) doivent etre de préférence lisibles (ah je vous l'ai dit c'est idiot !) et surtout représentatif.
il est plus simple d'identifier une variable qui s'appele $contenu que $xWz92.
perso, lorsque j'ai pas le choix je vire les voyelles (genre sqlite_query devient sqlt_qr). avec l'habitude ca reste lisible (je crois qu'on appele ca notation hebraique mais je suis pas sur )

bon voila,
en gros,
vous fachez pas,
je fais pas expres vous savez...

Pour autant, je ne vois pas de meilleure solution que celle ci. A vrai dire, la construction de mon fichier index est des plus simple, elle oriente tout de suite le développeur, supprime toute forme de code html ... Je veux bien quelques précisions à cet égard.

Pour moi, chaque page doit se suffire à elle même.
De plus, le soucis avec un index unique, c'est qu'il n'y a pas d'enchainement logique sans passer par ce fichier et, donc, qu'il est très facile de se retrouver avec des dizaines de tests et d'inclusions qui, plus le projet grossira, plus aura tendance à perdre le développeur qui cherchera sa petite ligne.

Je préfère avoir une sorte de template qui est, lui, inclus dans chaque page et qui contient les fonctions standard (affichage, vérification, connexion, connexion BdD) qu'une page qui serve de carrefour au reste de l'application

Les caractères, je peux effectivement les changer. Jusqu'à présent, effectivement, je copiais les lignes de commentaires. Par contre, le fait de les limiter à 80 caractères, c'est clairement voulu. 80 caractères, c'est pile la largeur d'impression sur une page, du coup, quand on commente les lignes, ça devient un réflexe de pratiquer ainsi. Les commentaires sont uniformes, également.

Certes, mais cette notion de 80 caractères ne me plait pas pour la simple et bonne raison que je ne pense pas qu'on imprime son code tout les 2 jours et que cette limite saute dès qu'on change de configuration d'écran.

Pour uniformiser les commentaires, j'utilise le

//----------                     <= 10 tirets
//-- mon commentaire    <= 2 tirets, le commentaire
//-- sur plusieurs lignes  <= 2 tirets, le commentaire
//----------                     <= 10 tirets

Et je trouve que c'est tout aussi lisible, tout autant en évidence et moins dépendant de la configuration de l'écran

Ca va se construire doucement, ce livret.

J'espère bien
Et compte sur moi pour t'aider

Pour moi, chaque page doit se suffire à elle même.
De plus, le soucis avec un index unique, c'est qu'il n'y a pas d'enchainement logique sans passer par ce fichier et, donc, qu'il est très facile de se retrouver avec des dizaines de tests et d'inclusions qui, plus le projet grossira, plus aura tendance à perdre le développeur qui cherchera sa petite ligne.

C'est une question de conception là ... C'est peut être un paragraphe que je devrais supprimer, les préférences de chacun n'ont rien à voir avec ce livret, à mon sens. Je vais revoir ça.

Certes, mais cette notion de 80 caractères ne me plait pas pour la simple et bonne raison que je ne pense pas qu'on imprime son code tout les 2 jours et que cette limite saute dès qu'on change de configuration d'écran.

Hum, il va falloir réfléchir à ça. J'avoue que d'autres réactions à cet égard auraient leur utilité.

Pour uniformiser les commentaires, j'utilise le

//----------                     <= 10 tirets
//-- mon commentaire    <= 2 tirets, le commentaire
//-- sur plusieurs lignes  <= 2 tirets, le commentaire
//----------                     <= 10 tirets

A envisager, mais là, il faudrait vérifier en réalité en fonction des générateurs de documentation. Ou puis-je me renseigner ?

A envisager, mais là, il faudrait vérifier en réalité en fonction des générateurs de documentation. Ou puis-je me renseigner ?

http://cyberzoide.developpez.com/php4/phpdoc/

Tu as la liste des générateurs, à partir de leur doc propre tu auras tes réponses.

Sachant que généralement c'est assez simple :

/**
 * Fonction qui calcule la somme de deux nombres
 * @param int nombre1
 * @param int nombre2
 * @return int somme
 */

Donc pas besoin de mettre des tas de tirets ou de tildes ou autre trucs bizarres

A envisager, mais là, il faudrait vérifier en réalité en fonction des générateurs de documentation. Ou puis-je me renseigner ?

http://cyberzoide.developpez.com/php4/phpdoc/

Tu as la liste des générateurs, à partir de leur doc propre tu auras tes réponses.

Sachant que généralement c'est assez simple :

/**
 * Fonction qui calcule la somme de deux nombres
 * @param int nombre1
 * @param int nombre2
 * @return int somme
 */

Donc pas besoin de mettre des tas de tirets ou de tildes ou autre trucs bizarres

De plus, ce modéle est intégré dans Zend Studio, donc ce doit être le modéle de prédilection non ?

Un détail à propos des délimiteurs <?php et surtout ?> :

Balises d’ouverture et de fermeture de PHP
*** IMPERATIF ***
L’ouverture du code doit impérativement être réalisée avec la balise < ?php (en
minuscules). La fermeture avec la balise ?>.

D'accord pour l'ouverture, mais attention à propos de la fermeture :

A.2.1. Général

Pour les fichiers contenant uniquement du code PHP, le tag de fermeture ("?>") n'est jamais permis[Note de Cyrano : lire "dans l'écriture de classe pour le ZF"]. Il n'est pas requis pas PHP. Ne pas l'inclure permet de prévenir les problèmes liés à l'injection accidentelle d'espaces blancs dans la sortie.

Source : Documentation du Zend Framework

Par contre, le fait de les limiter à 80 caractères, c'est clairement voulu. 80 caractères, c'est pile la largeur d'impression sur une page, du coup, quand on commente les lignes, ça devient un réflexe de pratiquer ainsi. Les commentaires sont uniformes, également.

Heu...dans quelle police ? En quel corps ?[/url]

Par contre, le fait de les limiter à 80 caractères, c'est clairement voulu. 80 caractères, c'est pile la largeur d'impression sur une page, du coup, quand on commente les lignes, ça devient un réflexe de pratiquer ainsi. Les commentaires sont uniformes, également.

Heu...dans quelle police ? En quel corps ?[/url]

ça sent le vieux reliquat de notepad ça

Concernant les accolades j'ai pris l'habitude de faire comme ça :

for() {

}

while() {

}

Je l'ai déjà vu chez d'autre mais je ne sais pas si c'est courant...

Concernant les accolades j'ai pris l'habitude de faire comme ça :

for() {

}

while() {

}

Je l'ai déjà vu chez d'autre mais je ne sais pas si c'est courant...

C'est en tous cas ma façon de faire. Pour tout ce qui est structure de contrôle (if, else, for, while, etc...) l'accolade ouvrante est sur la même ligne. Ceci me permet d'insister dans la forme sur le fait que la structure de contrôle est une partie intégrante du bloc de code en cours.
À l'inverse les fonctions et classes voient leur accolade ouvrante à la ligne, pour la raison opposée bien sûr

J'ai la facheuse tendance de mettre les accolades a la ligne pour les if et les else, ainsi que pour les classes et fonctions (sauf en javascript, je sais pas pourquoi )
Mais sinon, le seul cas ou je mets l'accolade sur la même ligne, c'est pour les switch...

@+

Par contre, le fait de les limiter à 80 caractères, c'est clairement voulu. 80 caractères, c'est pile la largeur d'impression sur une page, du coup, quand on commente les lignes, ça devient un réflexe de pratiquer ainsi. Les commentaires sont uniformes, également.

Heu...dans quelle police ? En quel corps ?[/url]

Disons, la police du bloc notes, qui est utilisée à priori dans tous les logiciels de développement.

Quelque soit le caractère que j'utilise sous phpedit, je peux l'envoyer 80 fois avant d'avoir ma barre de fractionnement de la page.