Alors pour ma part j'utilise dans al-gol des conventions décrite dans un document à destination des éventuel développeur qui voudrait rejoindre le projet, en voici donc un extrait:
Citation :Les commentaires
Il y a 2 types de commentaire:
- Les commentaires du code :Ils servent à savoir ce que fait un bout de code
- Les commentaire de génération de doc :Ils servent à générer la doc de toutes les pages, fonctions, classes, méthodes, variables du projet. Pour ces derniers il faut suivre la syntaxe de http://www.PHPdoc.org .
Les commentaires doivent être en français car le projet n'a pas pour intention d'accueillir des codeurs non francophone.
Convention de nommage
- Les noms en anglais:
Il est demandé de nommer les variables, et autre nom de page, méthode ou autre en anglais.
Ceci afin de garder une homogénéité avec le code natif de php
- Les fichiers contenus dans un sous répertoire (différent de db et doc) doivent porter leur noms, exemple:
Autorisé: /lang/fr/upload.fr.php /index.php /class/upload.class.php /media/css/book.css /media/tpl/book.tpl.php
Interdit: /class/upload.php
- Les répertoires doivent avoir des noms uniques.
- Tous les noms doivent être en minuscule.
- On utilise toujours le _ plutôt que le -.
Règle de codage
Code PHP :<?php
public static function exemple() {
while ($ma_condition_ultra_supra_longue_qui_prend_plus_de_80_caracteres)
echo 'mon instruction se place alors en dessous et indenté';
$tableaux=array(
'id' => 'test',
'id_long' => 'test',
'id2' => 'test',
'id3' => 'test'
);
if (true) {
echo 'zut';
return false;
}
else echo 'la ligne est courte pas besoin de mettre en dessous!';
}
- L'indentation doit être de 4 espaces
- L'accolade ouvrante doit se trouver sur la même ligne que la structure de contrôle (if,else, switch, while...)
- L'accolade fermante doit se trouver au même niveau que la première lettre de l'instruction de la structure de contrôle
- Si il n'y a qu'une seul action, les accolades peuvent être omise. Dans ce cas l'actions doit être sur la même ligne que l'instruction de la structure de contrôle OU sur la ligne du dessous avec un décalage d'une indentation si la lisibilité s'en trouve gêné (condition trop longue).
- Les longs array doivent être présenté comme dans l'exemple
- [TODO] Tris des méthodes (alphabétique?)
Il y aussi des conventions pour l'arborescence des fichiers.
Et je part du principe qu'une méthode/fonction ne doit faire qu'une action et que son code doit se concentrer la dessus. Par exemple, pas question de mettre if ($number>0) $text.='s'; en plein milieu d'une méthode d'affichage d'un message, car sa génération n'est pas de son ressort.
Sinon je porte beaucoup d'importance à l'écriture d'un fichier de test pour chaque classe, avant même que celle ci soit créer voir même complètement conceptualisé. Cette technique permet de voir comment doit réagir la boite avant même son existence. La revue de ce fichier peut être faite pendant qu'on code la classe proprement dite si une idée vient.
A la fin le code est revu, réorganisé, simplifié, les commentaires phpdocumentor complété si inexistant. La classe est alors considéré comme stable.
Je n'utilise pas de framework pour l'instant, mais j'y viendrait peut être, par contre j'utilise une organisation MVC basique de mon cru.