Les bonnes pratiques – Conventions générales
L’utilisation de bonnes pratiques permet d’obtenir un code plus lisible, plus facile à maintenir, et permet d’éviter de nombreuses erreurs. Je vous présente ici les conventions utilisées sur ce site, mais il n’y a pas de réelle norme, chaque développeur, chaque équipe peut définir ses propres « bonnes pratiques ».
Leur point commun sera une standardisation de l’écriture du code, comme c’est le cas lorsque l’on utilise un framework tel que symfony ou encore Zend Framework.
Règles de nommage
De manière générale, donnez à vos fichiers, à vos fonctions, classes, méthodes et variables des noms explicites, de longueur raisonnable, en séparant les mots de manière visuelle en mettant la première lettre en majuscule (lowerCamelCase), à l’exception des constantes, dont le nom entier est par convention en majuscules, avec un underscore : _ pour séparer les mots.
L’usage veut que l’utilisation de l’underscore en début de méthode soit réservé aux méthodes déclarées private, et le double underscore aux méthodes dites magiques :__construct(), __destruct(), __call(), __toString(), etc..
# variable
$typeFichier = 'xml';
# fonctions, classes et methodes
function convertirTypes () {...
class exporterDonnees {...
public function exporterVersFichier () {...
# methode privée
private function _accesPrive () {...
# constantes et constantes de classe
define('NOM_FICHIER', 'fichier.php');
const NOM_FICHIER = 'fichier.php';
Si deux variables, classes, fonctions ont des noms trop proches, vous courez le risque de les confondre. Cherchez à les différencier au maximum, qu’il ne puisse y avoir aucune confusion possible. Une des méthodes que vous pouvez utiliser en pareil cas est la « notation hongroise », qui consiste à préfixer une variable par son type.
# entier (integer) $iVariable = 1; # chaîne de caractères (string) $strVariable = 'des caractères'; # booléen (true/false) $bVariable = true;
De même on admettra fn comme préfixe à une fonction ou à une méthode que vous avez développée s’il y a risque de confusion avec une fonction prédéfinie de PHP.
# fonction intégrée à PHP
split()
# ma fonction de split personnalisée
function fnSplit() {...
Règles de lisibilité
Ces règles concernent l’espacement des opérateurs, l’indentation, le placement des accolades, les lignes blanches, etc.
Préférez-vous relire ce code :
if($bVariable===true){
$iVariable=1+1;
}else{
$iVariable=2+2;
}
$monAutreVariable='...
ou celui-ci :
if ($bVariable === true) {
$iVariable = 1 + 1;
}
else {
$iVariable = 2 + 2;
}
$monAutreVariable = '...
On retiendra donc qu’il est préférable, voire indispensable d’aérer son code en insérant des espaces, des lignes blanches, en indentant son code et en passant les accolades fermantes sur une nouvelle ligne.
Commentez votre code
Documenter son code n’est pas une option, cela vous permettra de gagner un temps précieux à la relecture, pour débugger ou maintenir votre application. Aujourd’hui, dans 3 jours, vous vous souviendrez du pourquoi et du comment de chaque ligne, de chaque fonction. Et dans 6 mois ?
Il existe 4 types de commentaires en PHP : sur une seule ligne, en utilisant un double slash (//) ou le signe dièse (#), sur une ou plusieurs lignes en utilisant slash étoile / étoile slash (/* */), sur plusieurs lignes avec le format PHPDoc, slash étoile étoile / étoile (en début de ligne) / étoile slash (/** * */).
// un commentaire sur une ligne # et un autre toujours sur une seule ligne /* ce commentaire peut être multiligne si nécessaire */ /* ou tenir sur une seule ligne */ /** * enfin ce commentaire * au format PHPDoc * est lui aussi multiligne * et permet d'utiliser les tags @name, @var, @dparam, @return, @todo, etc. * afin de générer une documentation au format éponyme */
Voilà, nous avons passé en revue des pratiques simples, mais qui vous permettrons d’accroître votre productivité.
