Les règles de la bonne programmation en php

Soyez le premier à donner votre avis sur cette source.

Snippet vu 23 396 fois - Téléchargée 27 fois

Contenu du snippet

Voici un tutorial sur les règles du PHP5 et aussi du PHP4 pour les configurations !
Il est conseillé de les suivre et de ne pas dire "Mais ça marche quand même de la manière que je fais !"
Pourquoi est-ce conseillé de suivre ses règles ? Tout simplement, votre site sera plus portable, et fonctoinnera avec les meilleurs fonctionnalitées.

Voici les règles pour PHP 4 ou 5 avec les variables à respecter.
Vous allez dans votre php.ini et vous modifier ces variables. Si votre site professionel (ou hébergement profesionnel) ne vous permet pas de changer ces variables, je vous conseille de tester le tout chez vous avec les bonnes variables. Ainsi, si vous changez d'hébergeur, et que celui-ci n'a pas les mêmes configurations, vous n'aurez aucun problème à faire fonctionner votre site.

short_open_tag = Off
Cette variable vous oblige à débuter vos scripts avec <?php et non plus <?. La variable short_open_tag va de plus en plus disparaître au cours du temps. Donc c'est à vous de bien programmer et de penser à utiliser <?php au lieu de <?
Attention, vous ne pouvez plus non plus utiliser <?=, il faut utiliser <?php echo
Auparavant, vous pouviez aussi coder immédiatement apres la balise comme <?if, mais maintenant, il faut y mettre un espace : <?php if...

register_globals = Off
Cette variable permet d'améliorer la sécurité de vos sites web. Elle vous oblige à utiliser les variables superglobales au lieu d'utiliser des variables simples.
Lors d'un envoi d'un formulaire, vous spécifiez la méthode et vous devez donc utiliser cette variable comme $_POST['variable'] ou $_GET, au lieu de $variable directement.
Même chose pour les variable $_SERVER, $_COOKIE, $_ENV...

error_reporting = E_ALL
Cette variable vous oblige à bien coder car elle va afficher toutes les erreurs possibles que le site peut générer. Vous avez surement un error_reporting qui empêche les erreurs NOTICE d'apparaître.
Si vous avez un NOTICE qui dit "Unidentified Variable", c'est parce que vous n'avez pas défini cette variable auparavant.
Vous ne pouvez pas faire un echo $_POST['variable'], si $_POST['variable'] n'existe pas auparavant...
C'est pour ca qu'il faut utiliser la fonction isset()
if(isset($_POST['variable']))
$variable = $_POST['variable'];
else
$variable = "";

display_errors = On
Bien que sur certains sites cette variable est à Off car il est dit que pour les sites professionels, il ne doit pas y avoir d'erreur qui apparait.
Si vous codez bien, même si cette variable est à On, il n'y aura pas d'erreur qui apparaîtra ;)

allow_call_time_pass_reference = Off
Avant, cette variable était réglé sur On... Elle permetait de passer à la volé des variables par référance à l'APPEL des fonctions.
Maintenant, si vous voulez passer une variable par référence, vous devez le définir dans la création de la fonction.
Mais au fait ? c'est quoi ca référence ?
Une variable par référence permet de passer un "pointeur" (pour les pro, c'est pas géré comme un pointeur à la base) vers une adresse mémoire.
Mais c'est quoi un pointeur ?
Lorsque vous passez une variable à une fonction (sauf les ressources) vous en faites une copie... Si vous la passez par référence, vous donner l'adresse mémoire de cette dernière. Ce qui a pour influence que vous pourrez modifier le contenu de cette dernière.
Exemple
function test(&$a){
$a = 5;
}
$bou = 3;
test($bou);
// $bou vaut maintenant 5;

Autres conseils :
Ne pas utiliser $_REQUEST... Ceci accepte les $_POST et $_GET. Vous savez d'ou vient votre variable, alors utiliser $_POST ou $_GET !

############################# AJOUT 2 AOUT 2004
Suite aux commentaires reçu dans ce post et dans d'autres, je post ce petit ajout sur les règles de la bonne programmation.

Recherche/Remplacement
Pour faire de la/du recherche/remplacement dans un texte, il est plus rapide d'utiliser les fonctions str_. Si vous devez trouver des choses plus compliqués vous pouvez utiliser ereg_. Par contre, il encore mieux d'utiliser les fonctions preg_ car celles-ci sont plus rapides.

echo/print
Si vous voulez gagner en rapidité, il est préférable d'utiliser echo car print retourne une valeur. Vous pouvez aller voir sur http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40.
Par contre, si vous souhaitez formater du texte, il est préférable d'utiliser printf ou sprintf.

SQL
Lors de requète SQL, il est préférable d'utiliser le nom des champs exacts plutot que d'utiliser la clé *. (SELECT * FROM...)
Pourquoi ? Parce que dans votre script, vous n'utiliserez certainement pas TOUS les champs que vous allez obtenir. De plus, si l'ordre des champs change il pourrait y avoir des problèmes avec votre code. (voir plus bas). MÊME si votre sql fais 10 mètres de long parce que vous placez des champs, je pense qu'il est préférable de faire ainsi !
Il est mieux d'utiliser la constantes MYSQL_ASSOC plutot que MYSQL_NUM (ou MYSQLI_...). Pourquoi ? parce que de cette manière, vous allez obtenir $var['champ'] plutot qu'un d'un numéro qui pourrait changer : $var[5].

La concaténation
Il est préférable de concaténer vos variables plutot que de les afficher directement dans vos strings.
Exemple : $var = "Something " . $other;
Plutot que $var = "Something $other";
Ici les 2 vont fonctionner mais il est préférable de faire le premier exemple parce que si vous devez afficher un tableau multidimensionnel par exemple, vous DEVREZ le concaténer. Donc, il suffit de lire "L'art de la Régularité" plus bas.
Je pense qu'il est préférable d'utiliser une concaténation avec des points (.) plutot qu'avec des virgules (,) parce que le standart est quand même le point et que sur php.net vous verrez rarement une concaténation à virgule.

Apostrophe/Guillemet
Lors d'un affichage d'un simple texte, il est dit que c'est plus rapide d'utiliser les apostrophe car PHP ne remplace pas les variables dans le texte entre apostrophes. Par contre ici, il suffit de suivre "L'art de la Régularité" cité plus bas.

include_once
Lorsque vous insérer plusieurs fichiers (include) car vous êtes maintenant rendu au stade ou vous programmer modulairement (oui ca prend du temps). Plusieurs fichiers ont besoin de d'autres pour fonctionner. Donc logiquement, vous les appeler avant. Mais pour être encore plus logique, il serait préférable de faire un include_once au début de ces fichiers qui ont besoin des fichiers précédemment appeler.
Pourquoi ? Parce que comme en C, vous faites des #include afin de montrer que certaines fonctions sont dans d'autres fichiers et vous en aurez besoin. include_once signifie que vous n'appelerai le fichier qu'une seule fois. PHP va savoir si le fichier est déjà chargé. De plus comme avantage, si jamais vous vouler utiliser que le fichier x.php, vous verrez IMMÉDIATEMENT de quels autres fichiers il a besoin.
Question rapidité ? Il est peut-etre vrai que vous perdez quelque milisecondes avec beaucoup d'include_once mais je ne pense pas que ca soit ca qui compte. D'autres vont préferer de faire "// Ajouter le fichier y.php" en commentaire en haut du fichier. Mais il est préférable de faire ces include_once car vous n'aurez pas à modifier le code si vous prenez par exemple les fichiers requis et que vous les déplacez dans un autre dossier !

include/require ?
La différence entre les 2 est que require va emettre une Fatal Error alors que include va emettre un Warning si le fichier à inclure n'est pas trouvé

L'art de la Régularité
Essais d'être régulier dans vos codes. Si vos tableaux vous les appeler avec des apostrophes ($var['test']) et parfois avec des guillemets ($var["test"]), vous ne garderez pas une régularité. Employez une des deux notations et gardez la ! (Ici il est préférable d'utiliser les aportrophe question de rapidité).
Ceci ne vaut pas seulement pour les apostrophes et appel de tableau, mais aussi par exemple les appels de fonctions (FOpen, et fopen font la même chose, mais gardez dont l'habitude de faire que fopen). Même chose avec print et echo.

L'affichage des erreurs (@)
Il est vrai que sur un site web professionel on ne doit pas voir les erreurs. L'utilisation de @ est à proscrire ! Il vaut mieux essayer de trouver le problème plus haut dans votre code plutot que d'executer des lignes et des lignes inutiles...
Par exemple, lors de la connexion à une base de données. Vérifiez si vous êtes connecté avant de faire un query. Même chose pour un fetch_array, vérifier que votre Query est bon ! Ainsi, vous éviterez d'utiliser les @.
La seule utilisation que vous pouvez faire car vous n'avez pas le choix, c'est par exemple à la connexion de la base de données... Ici vous pouvez quand même faire un if, mais il vous sortira un Warning ou une Notice. Vous pouvez cacher ces erreurs, mais gérer les !

Fonctions Modulaires
Une fonction modulaire est une fonction qui peut fonctionner partout ! sans avoir besoin de 3000 autres lignes de code. À l'utilisation de ces fonctions, un utilisateur n'aurait pas besoin de comprendre ce qu'il y a dedans, mais seulement ce que l'on doit mettre et ce qu'il y a en sortie.
Si une fonction doit absolument recevoir du texte, mettez une vérification "si int... transforme le en string". Toutes ces genres de vérification doivent être faites DANS la fonction et pas par l'utilisateur dans son script.
Vous allez dire "Oui mais, c'est moi qui code, je ne suis pas con à mettre un int alors que je sais qu'il faut un string". Ok, mais si d'autres ne font pas expres et placent un int... ?

Fontions Modulaires : La gestion d'erreurs
Une bonne gestion d'erreur sur les fonctions modulaires est très utile. Si vous devez retourner un string par exemple, et qu'il y a une erreur, alors retournez FALSE. En PHP, même chose pour les int... retournez FALSE (pourquoi je dis en PHP ? parce que en C++, si on doit retourner un int, alors on a l'habitude de retourner -1 en cas d'echec par exemple...)
Si votre fonction existe plusieurs points de sorties en tant qu'erreur (des return FALSE) et un return TRUE en tant que réussite, vous pouvez retourner des codes d'erreur. (return 1, return 2...) Ainsi, vous faites un commentaire en haut de votre fonction et vous expliquez ... Si 1 alors ... si 2...
Si cette fonction a bien fonctionné, au lieu de retourner TRUE, vous retournez 0. Zéro signifie que la fonction s'est terminé correctement.

############################# AJOUT 13 AOUT 2004
Fin du Script
À la fin de votre script, assurez vous de fermer toutes les choses que vous avez ouverte lors de son exécution même si la documentation vous affirme que cela se fait tout seul, il est préférable de le faire par vous même.
Par exemple pour les connexions SQL, les fichiers, les classes (créées dynamiquement), ...

PHP5 et les Classes
  • Les mots-clés private, public, et protected

Ces mots-clés servent à définir la portées des variables et des fonctions. Sachez que vous ne pouvez pas les utiliser sur les fonctions définies par PHP (ex: __construct()).
private : Les variables ou fonctions private seront accessibles par la classe seulement qui possède la variable ou la fonction.
public : Les variables ou fonctions public seront accessibles dans tout le script ! Ceci est la valeur par défaut des variables et fonctions. Il est déconseillé de l'utiliser partout !
protected : Les variables ou fonctions protected seront accessibles par la classe même ou les classes parentes à celles-ci.
  • Les Constructeurs et Destructeurs

Auparavant les constructeurs en PHP5 étaient écrit de la sorte :
function nom_de_la_classe()
et il n'y avait aucun destructeur. Maintenant le constructeur est __construct() et destructeur __destruct(). Sachez que vous ne pouvez les appeler directement.
Aprenez à bien utiliser __destruct() ! Si votre classe ouvre un fichier dans __construct(), eh bien fermez le dans __destruct() !

Classe pour mySQL et mySQLi et autres
Les technologies changeant rapidement ainsi que vos pages, je souhaite pour vous que vous n'ayez pas à retaper tout un code si vous devez changer d'hébergeur !
C'est pour quoi je vous propose la classe suivante :
http://www.phpcs.com/code.aspx?id=24813
Allez y jeter un coup d'oeil

Conclusion :


Si vous avez d'autres questions ou des commentaires, n'hésitez pas à les poser ici.
Maintenant, vous n'avez plus de raison de dire "Mais ca marche quand même" ou de ne pas bien programmer ;)
Si vous postez initié ou expert, essayez dont de suivre ces standards !

A voir également

Ajouter un commentaire

Commentaires

kegi
Messages postés
164
Date d'inscription
jeudi 23 octobre 2003
Statut
Membre
Dernière intervention
25 août 2008

Woaw, le 100e commentaire.
S'il y à autant de commentaires, c'est pas pour rien :P

good job (= "bon travail" : pour les "pro-francophones").

Joyeux temps des fêtes.
Kevin.
cs_GRenard
Messages postés
1662
Date d'inscription
lundi 16 septembre 2002
Statut
Membre
Dernière intervention
30 juillet 2008
1
C'est écrit plus bas que tu peux l'utiliser pour constructeur... mais pas en tant que "nom de fonction"...
C'est un peu mal dit je l'avoue... mais ça date de 2004 :)
J'aime bien WEBDEB qui cite la doc, :) car j'en ai écrit une bonne partie...
La doc française est super en retard, tout le monde qui travaillait dessus a d'autres projets pour l'instant et je crois qu'elle est rendue à 50% de synchronisée à ce jour.
cs_adoy
Messages postés
11
Date d'inscription
lundi 15 juillet 2002
Statut
Membre
Dernière intervention
2 janvier 2008

"Sachez que vous ne pouvez pas les utiliser sur les fonctions définies par PHP (ex: __construct())."

Il me semble que tu peux ;-) sinon comment créer tes singletons et autres designs paterns :-p
webdeb
Messages postés
488
Date d'inscription
samedi 5 avril 2003
Statut
Membre
Dernière intervention
31 mars 2009
3
Je reviens sur le display_errors et la @ :

* le display_errors ne devrait pas rester à On en environnement de production mais uniquement dans un environnement de test. Si un site est bien fait, il devrait être mis en production après avoir suivi le cycle minimal : développement -> test -> (recette) -> production.

Ainsi, en théorie, il ne devrait pas y'avoir de bugs sur le serveur de production. Mais malheureusement dans la réalité, il y'aura toujours une petite erreur pour trainer à un endroit. C'est pourquoi il est recommandé de laisser à On le display_errors en développement pour débugguer plus facilement (cad sans avoir à aller chercher constamment dans les logs de PHP les dernières erreurs générées par l'interprêteur), puis de le désactiver sur le serveur de production. Par contre, en production, on continue de logguer les erreurs dans le fichier de log en vue d'une consultation ultérieure pour débugguer. On peut également mettre à On la directive "ignore_repeated_error" qui permet de ne logguer qu'une seule fois une même erreur générée dans le but de limiter les écritures dans le fichier de logs et également le poids de celui-ci.

* L'arobase est, comme tu le dis, à proscrire mais tu ne dis pas non plus pourquoi. Il y'a tout d'abord la première raison logique que tu évoques, à savoir : traiter les erreurs plutôt que de les cacher. Je suis parfaitement d'accord sur ce point là. En revanche, tu omets de préciser qu'un arobase est extrêmement coûteux en performances. Pourquoi ? Et bien en fait, l'opérateur @ réalise implicitement les opérations suivantes :

- mémorisation de la valeur du display_errors dans une variable temporaire ($tmp = ini_get('display_errors') );
- mise à jour du display errors sur Off : ini_set('display_errors',1);
- interprétation de la ligne
- mise à jour du display errors à On : ini_set('display_errors', $tmp)

Ce qui donne dans la réalité :

$tmp = ini_set('error_reporting', 0);
action();
ini_set('error_reporting', $tmp);

Au final : 2 ini_set() à la suite ====> opérations extrêmement coûteuses.

C'est pourquoi, il est recommandé en production en production :

1/ De ne pas avoir de @ mais de traiter les erreurs qui peuvent être générées
2/ Placer le display_errors sur Off pour ne pas afficher les erreurs s'il en reste que l'on n'a pas détectées.

Voilà pour ce complément d'infos.

++

Hugo.
shoghi
Messages postés
18
Date d'inscription
jeudi 19 septembre 2002
Statut
Membre
Dernière intervention
18 septembre 2007

Tout simplement Bravo pour ce tuto.


Shoghi

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.