Quel est le paramètre error_reporting () recommandé pour le développement? Qu'en est-il d'E_STRICT?
-
09-06-2019 - |
Question
J'utilise généralement E_ALL
pour voir tout ce que PHP pourrait dire sur mon code pour essayer de l'améliorer.
Je viens de remarquer une constante d'erreur E_STRICT
, mais je n'ai jamais utilisé ou entendu parler de cela, s'agit-il d'un bon paramètre à utiliser pour le développement? Le manuel dit:
Avis d'exécution. Permettez à PHP de suggérer des modifications à votre code afin d’assurer la meilleure interopérabilité et la compatibilité en aval de votre code.
Je me demande donc si j'utilise le meilleur niveau rapport_erreurs
avec E_ALL
ou si cela avec le code E_STRICT
serait le meilleur? Ou y a-t-il une autre combinaison que je n'ai pas encore appris?
La solution
En PHP 5, les éléments couverts par E_STRICT
ne sont pas couverts par E_ALL
. Par conséquent, pour obtenir le maximum d'informations, vous devez les combiner:
error_reporting(E_ALL | E_STRICT);
En PHP 5.4, E_STRICT
sera inclus dans E_ALL
, afin que vous puissiez utiliser uniquement E_ALL
.
Vous pouvez également utiliser
error_reporting(-1);
qui activera toujours toutes les erreurs . Qui est plus correct sémantiquement que:
error_reporting(~0);
Autres conseils
Utilisez les éléments suivants dans le fichier php.ini:
error_reporting = E_ALL | E_STRICT
Vous devez également installer Xdebug , il permet de mettre en évidence vos erreurs en couleurs vives et de les imprimer de manière utile. des informations détaillées.
Ne laissez jamais aucune erreur ou remarque dans votre code, même s'il est inoffensif.
À mon avis, mieux vous fixez le niveau de signalement des erreurs en phase de développement, mieux ce sera.
Dans un environnement en direct, vous voulez un ensemble légèrement réduit (mais seulement légèrement réduit), mais vous voulez qu'ils soient consignés quelque part où ils ne peuvent pas être vus par l'utilisateur (je préfère syslog
).
http://php.net/error_reporting
E_ALL | E_STRICT
pour le développement avec PHP avant la version 5.2.0.
5.2 introduit E_RECOVERABLE_ERROR
et 5.3 introduit E_DEPRECATED
et E_USER_DEPRECATED
. Vous voudrez probablement les activer si vous utilisez l'une de ces versions.
Si vous voulez utiliser des nombres magiques, vous pouvez simplement définir la valeur error_reporting
sur une valeur assez élevée de 2 ^ n-1
- disons, 16777215
, ce qui activerait vraiment tous les bits entre 1..n
. Mais je ne pense pas que l’utilisation de nombres magiques soit une bonne idée ...
À mon avis, PHP a un peu lâché la balle en faisant en sorte que E_ALL
ne soit pas vraiment tout. Mais apparemment, ça va être corrigé en PHP 6 ...
Dans les nouvelles versions de PHP, E_ALL inclut davantage de classes d’erreurs. Depuis PHP 5.3, E_ALL inclut tout sauf E_STRICT. En PHP 6, cela comprendra même cela. C'est un bon indice: il vaut mieux voir plus de messages d'erreur que moins.
Ce qui est inclus dans E_ALL est documenté dans les constantes PHP prédéfinies . page dans le manuel en ligne.
Personnellement, je pense que le fait d’utiliser E_STRICT importe peu. Cela ne vous fera certainement pas de mal, d'autant plus que cela pourrait vous empêcher d'écrire des scripts qui risquent peu d'être endommagés dans les futures versions de PHP. Par contre, dans certains cas, les messages stricts peuvent être trop bruyants, peut-être surtout si vous êtes pressé. Je vous suggère de l'activer par défaut et de l'éteindre lorsque cela devient agaçant.
Vous pouvez utiliser error_reporting = -1
Il sera toujours composé de tous les bits (même s'ils ne sont pas dans E_ALL)
En fonction de vos plans de support à long terme pour ce code, le débogage avec E_STRICT
activé peut aider votre code à continuer de fonctionner dans un avenir lointain, mais il est probablement excessif pour une utilisation quotidienne. E_STRICT
doit être pris en compte pour deux raisons importantes:
- Conformément au manuel , la plupart des erreurs
E_STRICT
sont générées lors de la compilation. , pas d'exécution. Si vous augmentez le niveau d'erreur àE_ALL
dans votre code (et non via php.ini ), vous risquez de ne jamais voir d'erreurE_STRICT
. -
E_STRICT
est contenu dansE_ALL
sous PHP 6, mais pas sous PHP 5. Si vous mettez à niveau votre serveur vers PHP6, et que vous avezE_ALL
configuré comme décrit au point 1 ci-dessus, vous commencerez à voir les erreursE_STRICT
sans nécessiter de modification supplémentaire de votre part.
Il ne s'agit pas à proprement parler de rapport d'erreur, mais vivement , suggérons d'utiliser tout environnement de développement intégré affichant automatiquement les erreurs d'analyse et les problèmes courants (par exemple, une affectation dans une condition).
Cette fonctionnalité est activée par défaut dans Zend Studio for Eclipse. Depuis que je l’utilise, elle m'aide beaucoup à détecter les erreurs avant qu'elles ne se produisent.
Par exemple, je cachais certaines données dans la variable $ GLOBALS
dans cette partie de code, mais j’ai écrit par inadvertance $ _ GLOBALS
à la place. Les données n’ont jamais été mises en cache, et je ne savais jamais si Zend ne me l’avait pas dit: "Hé, cette chose $ _ GLOBALS
n’apparaît qu’une fois, cela pourrait être une erreur".
ini_set ("display_errors", "2"); ERROR_REPORTING (E_ALL);