ne jamais définir les parametre de configuration comme des variables
toujours des constantes chargées dès le début du script
ainsi il est impossible par quelque moyen que se soit de les modifier en cours d'exécution
choisir des règles de codages et s'y tenir
lire attentivement la littérature sur les design paterns concernant la programation (rechercher un élément dans une liste, tris, condition fonction etc.)
par exemple les règles de l'art disent sur une boucle un seul point d'entrée un seul point de sortie ce qui signifie pas de break les design patterns proposent toutes sorte d'algo pour respecter ce genre de contraintes
de même unfonction n'a qu'un point de sortie marqué par un retrun même si elle ne renvoie rien.
pour ma part j'y ajoute aucune chaine destiné (elle sont définies dans des fichiers dédiés) à l'interface n'apparait dans le code pas de print pas d'echo
il n'y a qu'un point qui envois la sortie
les éléments de production son stoqués indépendament du code (les templates permettent cela mais aussi DOM)
par exemple si je vérifie que la valeur d'un form est une date je ne fais pas
$error = 'Format de date invalide';
mais
$error = ERROR_STRING_INVALID_FORMAT;
ainsi il suffit de changer de template et de fichier de message pour adapter l'application.
je limites aussi les blocs de code à une 50ene de lignes plus généralement 20 à 30 audelà je fait des fonctions (methodes).
J'explicite toujours les indirections avec un commentaire
par exemple si j'ai un variable d'instance "map" qui contient le nom d'une classe je commente toujours
1 2 3 4
| $this->map = 'MaClasseAMoi';
...
//intentiation de la classe de Mapping
$mappedObject = new $this->map($params); |
car il est très difficiles de lire de telles indirection si la définition du nom de la référence est loin dans le code
je mets des acolade systématiques s'il peu y avoir une ambiguité de lecture
$this->$maVariable->myField;
est équivalent à
$this->{$maVariable}->myField;
et non à
$this->{$maVariable->myField};
par prevention je mets des accolades
Je sépare les différente couche de mon application
niveau View (interface externe GUI ou API)
niveau Logique d'interface (logique d'enchainement de l'interface)
niveau Logique Applicative (règles qui régissent ce que doit faire l'application)
niveau Logique metier (règles qui définissent les composants de l'application et non coment on les utilisent)
niveau accès aux données (DAO, File Net etc.)
L'accès au donné et utilisable par toute application
les objets metiers son commun à plusieurs applis
la logique applicative définit le coeur de l'application
la logique d'interface défini le comportement de l'interface
et la vue son apparence
A+JYT
Partager