On utilisera toujours les balises longues d'ouverture :

<?php
 
// Du code

Ceci n'est pas obligatoire mais fortement conseillé. On évite toute ambiguïté avec les PI^[2]. On s'assure également d'une compatibilité avec les configurations de bases de PHP.

Dans tous les fichiers, la balise de fermeture (?>) sera omise.

Les commentaires sont des portions de codes qui sont ignorées par le compilateur ou l'interpréteur. Dans le cas de PHP, c'est l'interpréteur.

On distingue 3 types de commentaires dans PHP : les commentaires en pleine ligne, de fin de ligne, et en bloc. PHP hérite de la syntaxe de commentaires de C, C++, Unix shell-style, et Perl. Dans Hoa, on utilise chaque type de commentaires dans un but précis :

On trouvera plus d'informations sur les commentaires en bloc d'en-tête sur la manuel de PEAR et surtout sur la page de PHPDocumentor.

Le nom des paquetages suit également une règle de nommage simple, mais pratique. Dans une arborescence Unix, les séparateurs de branches (si l'on considère une arborescence comme un arbre) sont des barres obliques (slash, /). Ici, on remplace tous les slashes par des traits de soulignements (underscore, _). La racine de l'arborescence n'est pas /, mais Hoa.

De cette façon, le paquetage qui se trouve dans :

./Hoa_Framework/Controller/Dispatcher/

, et qui gère la couche abstraite du contrôleur aura comme nom :

Hoa_Controller_Dispatcher_Abstract

Chaque premier caractère de mots est une majuscule, les suivants étant des minuscules, sauf si c'est un mot composé. Par exemple :

Hoa_XmlRpc_Client

On notera au passage que les acronymes et abréviations sont écris en minuscules.

Une classe d'entrée est une classe qui permet d'entrer dans un paquetage (et a fortiori de le démarrer, dans la plupart des cas). On a choisi de nommer les classes d'entrée de la même façon que son paquetage. Ainsi, la classe d'entrée du paquetage Mail est Hoa_Mail, qui se trouve dans le fichier Mail/Mail.php.

Il est très très rare qu'un paquetage ait une classe d'entrée qui n'ai pas le même nom que le paquetage. C'est le cas par exemple du paquetage Hoa_XmlRpc où l'on a deux classes d'entrée : Hoa_XmlRpc_Client et Hoa_XmlRpc_Server. Si on est dans un tel cas, ce sera de toute évidence précisé dans la documentation.

Les méthodes n'échappent pas à la règle. Elles ont également une convention de nommage.

Les noms des méthodes commencent par une minuscule. S'ils sont composés de plusieurs mots, chaque nouveau mot voit sa première lettre mise en majuscule.

Il peut arriver que des méthodes soient préfixées d'un trait de soulignement ; par exemple :

function _sendMail ( ... ) { ... }

Cela signifie que la méthode a un rôle particulier dans le fonctionnement du paquetage, et qu'elle ne doit pas être exploitée à l'extérieur. Il y a un rapport étroit avec la visibilité des méthodes, ou les couches abstraites.

Aucune méthode n'est préfixée de deux barres de soulignement. Cette syntaxe décrivant les méthodes magiques est réservée par PHP.

Les parenthèses délimitants les paramètres d'une fonction sont entourées par un espace :

function maFonction ( $paramA, $paramB )

Les règles d'accolade de fonction suivent les mêmes que pour les accolades de structures.

Différents styles existent pour la mise en page des accolades. Toutes se valent, ont des avantages et des inconvénients. Celle qui a été retenue dans Hoa est la suivante :

if(/* cond */) {
 
    // Alors …
}

De la même manière pour une fonction ou une méthode, on aura :

function maFonction ( $param = null ) {
 
    return $param;
}
 
class MaClasse {
 
    public function maMethode ( $param = TRUE ) {
 
        return $param;	
    }
}

Les tabulations dans Hoa sont des espaces ( ) et non des tabulations horizontales (\t, 	). Les tabulations ont alors une longueur de 4 espaces. On notera qu'une ligne vide ne comporte pas d'espace.

La longueur des lignes est tenue entre 80 et 100 caractères. Le maximum étant 100 et la taille idyllique étant 80. On utilise ces tailles pour une meilleur lisibilité du code.

Pour Vim, on aura les règles suivantes :

set expandtab
set shiftwidth=4
set softtabstop=4
set tabstop=4
set textwidth=80

Pour Emacs, on aura les règles suivantes :

(tab-with 4)
(c-basic-offset 4)
(c-hanging-comment-ender-p nil)
(indent-tab-mode nil)
(fill-column 80)

On rappelle la mise en forme des structures de contrôle adoptée dans Hoa :

if(condition1) {
 
    if(condition2 && condition3) {
 
        if(   condition4 && condition5
           && condition6 && condition6) {
 
            action1;
            action2;
        }
        else {
 
            action3;
            action4;
        }
    }
}
elseif(condition7) {
 
    action5;
    action6;
}
else
    action7;
 
for($i = $n; $i > 0; $i--) {
 
    action8;
    action9;
}
 
foreach($array as $key => $value)
    action10;
 
while(condition8) {
 
    action11;
    action12;	
}
 
do {
 
    action13;	
} while(condition9);
 
switch(condition10) {
 
    case 1:
        action14;
      break;
 
    case 2:
        action15;
      break;
 
    default:
        action16;
      break;
}
 
// Etc.

On donne suffisament d'exemples pour comprendre la philosophie choisie en terme d'espacement et de structure.

On distingue 2 types de constantes :

Toutes les constantes ont pour sépérateur de mots le trait de soulignement, et sont notées en majuscules.

Exception faite pour les constantes true, false et null qui sont notées en minuscules.

Les variables sont écrites en minuscules. Chaque nouveau mot est collé au précédent et commence par une majuscule. On utilise la notation CamelCase, excepté le fait que la première lettre est en minuscule.

Même si une variable devient trop longue (longueur supérieure à 10 caractères), on préfère qu'elle soit longue mais compréhensible plutôt que courte et incompréhensible.

Pour tous les autres noms de fichiers, de dossiers, ou n'importe quoi d'autre, on tente d'appliquer la convention CamelCase. À savoir seulement la première lettre de chaque mot en majuscule, et les mots sont collés les uns aux autres. Ainsi, tous les fichiers et dossiers commencent par une majuscule (attention, ça peut être une source d'erreur).

Tous les fichiers sont enregistrés comme des textes ASCII et utilisent l'encodage UTF-8.

Les configurations de PHP permettent la gestion des erreurs. Le comportement de ces configurations et fonctions est affecté par la configuration du fichier php.ini. Le rapport d'erreur peut se définir à travers ini_set ou plus simplement à travers la fonction error_reporting.

En PHP 5, un nouveau niveau d'erreur est disponible : E_STRICT. Ce niveau d'erreur inclut forcément le niveau d'erreur E_ALL, qui lui comprend tous les sous-niveaux. Donc toutes les erreurs seront affichées, même les plus strictes.

Activer E_STRICT pendant le développement est bénéfique. Les messages STRICT aident à utiliser la dernière et meilleure suggestion de méthode de codage. Par exemple, si une fonction est obsolète, n'est plus appréciée ou non recommandée, une erreur sera levée.

Développer avec un niveau d'erreur E_STRICT assure en parti un bon développement ou — du moins — une bonne utilisation du langage.