Coder proprement
Résolu
nougitch
Messages postés
431
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
17 novembre 2008
-
24 mars 2006 à 09:49
forresst Messages postés 1 Date d'inscription mardi 7 août 2001 Statut Membre Dernière intervention 26 mars 2006 - 26 mars 2006 à 10:39
forresst Messages postés 1 Date d'inscription mardi 7 août 2001 Statut Membre Dernière intervention 26 mars 2006 - 26 mars 2006 à 10:39
5 réponses
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
24 mars 2006 à 10:35
24 mars 2006 à 10:35
Hello,
tu sais, ça reste assez subjectif ce genre de trucs, et personne ne sera exhaustif sur le sujet. Et puis ça dépend des projets, aussi...
Bref, je vais te donner un url, déjà, puis essayer de faire le tour de ce que j'en pense moi.
L'url :
http://www.phpcs.com/codes/REGLES-BONNE-PROGRAMMATION-PHP_24870.aspx
Ensuite, sans être exhaustif probablement, donc :
- respecter une norme de programmation : à savoir, nom des fonctions, nom des variables, etc... Pourt ma part, en ce moment, mes fonctions (ou méthodes) sont de cette forme :
function setMyFile ()
Mes variables sont comme ceci :
$iCompteur (indique que c'est un compteur, et que c'est un entier - integer)
$sString : chaîne générique, de type chaîne, donc...(string)
$sQuery : chaîne de requête sql
$rRequete (par exemple hein) : un type ressource, provenan' d'un query ()
$aNomVilles : tableau de noms de villes (type array).
etc...
Mes classes sont généralement comme ceci :
class oMaClasse
et les instances :
$oMaClasse.
- Essayer de commenter, avec des commentaires aux normes. Exemple :
/**
* méthode privée getReturns
* sert à récupérer le code pour la/les valeur/s de retour de la méthode, si elle est documentée
* @Param string comments : contient une chaîne avec les commentaires de la méthode
* @Return array aTmp : contient un tableau avec les retours possibles
*/
public function getReturns (...) {
...
}
- indenter le code, tjrs de la même manière.
- tâcher de séparer le plus possible le code php du code html.
Côté programmation maintenant, réellement :
- perndre l'habitude de coder avec une bonne configuration php, et qui respecte les suggestions de php.net. Entre autres :
register_globals à Off
short_open_tag à Off (évite les embrouilles avec le xml et le xhtml)
register_long_array à Off
error_reporting à E_ALL
- toujours vérifier qu'une variable existe, et qu'elle est du type attendu le cas échéant (notamment pour des entrées utilisateurs, ou si un autre codeur va appeler ce code). Limiter au minimum les écarts possible entre ce qu'on attend et ce qu'on reçoit : donc, user et abuser des isset () empty () is_int () is_numeric () is_object () etc...
Et faire très attention aux types évidemment, en abusant de l'opérateur de comparaison typé : === ou !==
Quand une fonction peut renvoyer false, ou 0, et que ces résultats sont différents (strpos par exemple), ne jamais tester comme ça : if (strpos (...))...parce que forcépment, il y aura un jour un problèùe! Donc :
if (false !== strpos (...))
Pareil pour la lecture de répertoires classique, par exemple :
while (false !== readdir ())
- PHP est un langage TRES fourni en fonctions diverses et variées : il faut TOUJOURS préférer les fonctions natives de php, à un algo maison. Donc, quand on veut faire quelquechosen, on regarde d'abord si PHP ne possède pas une fonction qui le fait! Un exemple con : sur codyx.org (http://www.codyx.org/), le nouveau site de snippets de CS, on a un snippet pour inverser les caractères dans une chaîne. La plupart des langages parcourent la chaîne, chaque caractère, et les place dans une autre chaîne, en partant de la fin...PHP fait ceci : $sString = strrev ($sString);
C'est pas beau la vie ?
Pourquoi utiliser en priorité ces fonctions ? Parce qu'elle ssont natives, écrites en C, elles seront TJRS plus rapides qu'un algo maison écrit en php.
- saisies utilisateur : toujours les échapper!! TOUJOURS! Et toujours les vérifier, TOUJOURS! Ne jamais faire confiance à des données extérieures.
- echo est plus rapide avec des apostrophes. Après, virgule ou point, c'est au choix. Un intérêt des apostrophes autre :
echo ''; on peut garder les guillemets pour les attributs html.
Heredoc peut aussi parfois être utile, et plus clair surtout (mais attention à l'indentation du code html généré):
echo <<<HTML
HTML;
- les basiques, valables dans la plupart des langages :
éviter de doubler inutilement les variables
une boucle for évalue l'expression qu'elle contient à chaque itération, donc , on ne fait pas :
for ($i = 0; $i < count ($aTab); $i ++)
mais :
$iCpt = count ($aTab);
for ($i = 0; $i < $cpt; $i ++)
A moins que ce soit voulu parce que la taille du tableau est modifié dans la boucle, par exemple.
On n'utilise pas de variables non déclarées (de toutes façons, c'est impossible en error_reporting à E_ALL)
On crée des fonctions autant que possible, afin d'éviter les traitements redondants (ou on code en POO, au choix...)
On ne crée PAS de fonctions qui va simplement lancer 1 fonction interne php (c'est souvent tentant en POO justement), c'est inutile, c'est redondant, et c'est plus lent, forcément.
On fait bien attention aux possibilités des fonctions internes : un exemple trop fréquent:
$sString = str_replace ('.', ';', $sString);
$sString = str_replace (':', '!', $sString);
etc... alors que str_replace accepte des tableaux en paramètres! Bref, une ligne suffit, et on en voit souvent des 10aines à la suite...
Bon, la suite plus tard si je trouve d'autres trucs.
tu sais, ça reste assez subjectif ce genre de trucs, et personne ne sera exhaustif sur le sujet. Et puis ça dépend des projets, aussi...
Bref, je vais te donner un url, déjà, puis essayer de faire le tour de ce que j'en pense moi.
L'url :
http://www.phpcs.com/codes/REGLES-BONNE-PROGRAMMATION-PHP_24870.aspx
Ensuite, sans être exhaustif probablement, donc :
- respecter une norme de programmation : à savoir, nom des fonctions, nom des variables, etc... Pourt ma part, en ce moment, mes fonctions (ou méthodes) sont de cette forme :
function setMyFile ()
Mes variables sont comme ceci :
$iCompteur (indique que c'est un compteur, et que c'est un entier - integer)
$sString : chaîne générique, de type chaîne, donc...(string)
$sQuery : chaîne de requête sql
$rRequete (par exemple hein) : un type ressource, provenan' d'un query ()
$aNomVilles : tableau de noms de villes (type array).
etc...
Mes classes sont généralement comme ceci :
class oMaClasse
et les instances :
$oMaClasse.
- Essayer de commenter, avec des commentaires aux normes. Exemple :
/**
* méthode privée getReturns
* sert à récupérer le code pour la/les valeur/s de retour de la méthode, si elle est documentée
* @Param string comments : contient une chaîne avec les commentaires de la méthode
* @Return array aTmp : contient un tableau avec les retours possibles
*/
public function getReturns (...) {
...
}
- indenter le code, tjrs de la même manière.
- tâcher de séparer le plus possible le code php du code html.
Côté programmation maintenant, réellement :
- perndre l'habitude de coder avec une bonne configuration php, et qui respecte les suggestions de php.net. Entre autres :
register_globals à Off
short_open_tag à Off (évite les embrouilles avec le xml et le xhtml)
register_long_array à Off
error_reporting à E_ALL
- toujours vérifier qu'une variable existe, et qu'elle est du type attendu le cas échéant (notamment pour des entrées utilisateurs, ou si un autre codeur va appeler ce code). Limiter au minimum les écarts possible entre ce qu'on attend et ce qu'on reçoit : donc, user et abuser des isset () empty () is_int () is_numeric () is_object () etc...
Et faire très attention aux types évidemment, en abusant de l'opérateur de comparaison typé : === ou !==
Quand une fonction peut renvoyer false, ou 0, et que ces résultats sont différents (strpos par exemple), ne jamais tester comme ça : if (strpos (...))...parce que forcépment, il y aura un jour un problèùe! Donc :
if (false !== strpos (...))
Pareil pour la lecture de répertoires classique, par exemple :
while (false !== readdir ())
- PHP est un langage TRES fourni en fonctions diverses et variées : il faut TOUJOURS préférer les fonctions natives de php, à un algo maison. Donc, quand on veut faire quelquechosen, on regarde d'abord si PHP ne possède pas une fonction qui le fait! Un exemple con : sur codyx.org (http://www.codyx.org/), le nouveau site de snippets de CS, on a un snippet pour inverser les caractères dans une chaîne. La plupart des langages parcourent la chaîne, chaque caractère, et les place dans une autre chaîne, en partant de la fin...PHP fait ceci : $sString = strrev ($sString);
C'est pas beau la vie ?
Pourquoi utiliser en priorité ces fonctions ? Parce qu'elle ssont natives, écrites en C, elles seront TJRS plus rapides qu'un algo maison écrit en php.
- saisies utilisateur : toujours les échapper!! TOUJOURS! Et toujours les vérifier, TOUJOURS! Ne jamais faire confiance à des données extérieures.
- echo est plus rapide avec des apostrophes. Après, virgule ou point, c'est au choix. Un intérêt des apostrophes autre :
echo ''; on peut garder les guillemets pour les attributs html.
Heredoc peut aussi parfois être utile, et plus clair surtout (mais attention à l'indentation du code html généré):
echo <<<HTML
HTML;
- les basiques, valables dans la plupart des langages :
éviter de doubler inutilement les variables
une boucle for évalue l'expression qu'elle contient à chaque itération, donc , on ne fait pas :
for ($i = 0; $i < count ($aTab); $i ++)
mais :
$iCpt = count ($aTab);
for ($i = 0; $i < $cpt; $i ++)
A moins que ce soit voulu parce que la taille du tableau est modifié dans la boucle, par exemple.
On n'utilise pas de variables non déclarées (de toutes façons, c'est impossible en error_reporting à E_ALL)
On crée des fonctions autant que possible, afin d'éviter les traitements redondants (ou on code en POO, au choix...)
On ne crée PAS de fonctions qui va simplement lancer 1 fonction interne php (c'est souvent tentant en POO justement), c'est inutile, c'est redondant, et c'est plus lent, forcément.
On fait bien attention aux possibilités des fonctions internes : un exemple trop fréquent:
$sString = str_replace ('.', ';', $sString);
$sString = str_replace (':', '!', $sString);
etc... alors que str_replace accepte des tableaux en paramètres! Bref, une ligne suffit, et on en voit souvent des 10aines à la suite...
Bon, la suite plus tard si je trouve d'autres trucs.
nougitch
Messages postés
431
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
17 novembre 2008
24 mars 2006 à 11:04
24 mars 2006 à 11:04
Malalam, merci beaucoup !
Tes conseils sont précieux et pertinents.
Bien que je n'utilise pas encore tout ce dont tu as parlé, je suis content d'en savoir davantages, notamment en ce qui concerne la rapidité d'exécution du code.
Je pense que ce topic peut être très intéressant et j'espère que chacun viendra l'agrémenter pour nous faire part de ses conseils en termes de rapidité et de simplicité.
Pourquoi pas insérer sur le site une sorte de fiche pratique pour coder proprement et optimiser son travail ?
Que pensez-vous des 'include'/'require' pour éviter de se retrouver avec des pages à rallonge ?
P.S. : Il ne faut pas voir derrière cela une volonté d'uniformiser, voire même d'imposer un règlement.
Tes conseils sont précieux et pertinents.
Bien que je n'utilise pas encore tout ce dont tu as parlé, je suis content d'en savoir davantages, notamment en ce qui concerne la rapidité d'exécution du code.
Je pense que ce topic peut être très intéressant et j'espère que chacun viendra l'agrémenter pour nous faire part de ses conseils en termes de rapidité et de simplicité.
Pourquoi pas insérer sur le site une sorte de fiche pratique pour coder proprement et optimiser son travail ?
Que pensez-vous des 'include'/'require' pour éviter de se retrouver avec des pages à rallonge ?
P.S. : Il ne faut pas voir derrière cela une volonté d'uniformiser, voire même d'imposer un règlement.
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
24 mars 2006 à 11:34
24 mars 2006 à 11:34
Préférer : require_once '';
Mais oui, évidemment, tu mets tes fonctions dans un fichier requis, par exemple.
Quand on code POO, on fait pareil, on met ses classes dans des fichiers à part.
Mais oui, évidemment, tu mets tes fonctions dans un fichier requis, par exemple.
Quand on code POO, on fait pareil, on met ses classes dans des fichiers à part.
nougitch
Messages postés
431
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
17 novembre 2008
24 mars 2006 à 11:43
24 mars 2006 à 11:43
Très bien, merci.
J'attends la suite avec impatience.
J'attends la suite avec impatience.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
forresst
Messages postés
1
Date d'inscription
mardi 7 août 2001
Statut
Membre
Dernière intervention
26 mars 2006
26 mars 2006 à 10:39
26 mars 2006 à 10:39
Merci malalam !
Toutes ces infos sont très interressantes pour un débutant comme moi.
"Pourquoi pas insérer sur le site une sorte de fiche pratique pour coder proprement et optimiser son travail ?" dixit nougitch.
L'idée me parait très interressantes, elle permettrait une entraide pratique et de débuter avec de bonnes bases. Pour ma part je suis souvent craintif dans mes developpements : est ce que mon code est rapide, est que mon code est assez sécurisé, etc ...
Voila, c'est mon soutien personnel pour votre site et l'idée de nougitch.
En attendant aussi la suite ....
Toutes ces infos sont très interressantes pour un débutant comme moi.
"Pourquoi pas insérer sur le site une sorte de fiche pratique pour coder proprement et optimiser son travail ?" dixit nougitch.
L'idée me parait très interressantes, elle permettrait une entraide pratique et de débuter avec de bonnes bases. Pour ma part je suis souvent craintif dans mes developpements : est ce que mon code est rapide, est que mon code est assez sécurisé, etc ...
Voila, c'est mon soutien personnel pour votre site et l'idée de nougitch.
En attendant aussi la suite ....
