Pourquoi devrais-je corriger les erreurs E_NOTICE?

Question

En tant que développeur, je travaille avec E_NOTICE activé. Récemment cependant, on m'a demandé pourquoi les erreurs E_NOTICE devaient être corrigées. La seule raison pour laquelle j'ai pu trouver est qu'il est préférable de corriger ces problèmes.

Quelqu'un d'autre a-t-il des raisons de justifier le temps / coût supplémentaire dépensé pour corriger ces problèmes?

Plus précisément, pourquoi un gestionnaire devrait-il dépenser de l'argent pour les faire réparer si le code fonctionne déjà?

Answer 1

RÉSUMÉ

L' Exécution de PHP Configuration Docs vous donner une idée pourquoi:

Permettant E_NOTICE au cours du développement a certains avantages.

À des fins de débogage: AVIS de messages vous avertir d'éventuels bugs dans votre code. Par exemple, l'utilisation de valeurs non initialisées est averti. Il est extrêmement utile pour trouver les fautes de frappe et de gagner du temps pour le débogage.

Les messages d'information vous avertir de mauvais style. Par exemple, $arr[point] est mieux d'être écrit $arr['item'] depuis PHP essaie de traiter "item" comme une constante. Si elle n'est pas une constante, PHP suppose que c'est une chaîne.

Voici une explication plus détaillée de chaque...

---

1. POUR DÉTECTER LES FAUTES DE FRAPPE

La principale cause de l' E_NOTICE d'erreurs est des fautes de frappe.

Exemple - notice.php

<?php
$username = 'joe';        // in real life this would be from $_SESSION

// and then much further down in the code...

if ($usernmae) {            // typo, $usernmae expands to null
    echo "Logged in";
}
else {
    echo "Please log in...";
}
?>

Sortie sans E_NOTICE

Please log in...

Faux! Vous ne le voulais pas!

Sortie avec E_NOTICE

Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...

En PHP, une variable qui n'existe pas, retourne null plutôt que de provoquer une erreur, ce qui pourrait provoquer des code pour se comporter différemment que prévu, il est donc préférable de tenir compte E_NOTICE avertissements.

---

2. POUR DÉTECTER AMBIGUË LES INDICES DE TABLEAU

Il vous avertit également sur les indices de tableau qui pourrait changer sur vous, par exemple

Exemple de code ressemble à ça aujourd'hui

<?php

$arr = array();
$arr['username'] = 'fred';

// then further down

echo $arr[username];
?>

Sortie sans E_NOTICE

fred

Exemple - demain vous d'inclure une bibliothèque

<?php
// tomorrow someone adds this
include_once('somelib.php');

$arr = array();
$arr['username'] = 'fred';

// then further down

echo $arr[username];
?>

et la bibliothèque fait quelque chose comme ceci:

<?php
define("username", "Mary");
?>

Nouvelle sortie

Vide, parce que maintenant il s'affiche:

echo $arr["Mary"];

et il n'y a pas de clé Mary en $arr.

Sortie avec E_NOTICE

Si seulement le programmeur a E_NOTICE sur, PHP aurait imprimé un message d'erreur:

Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8
fred

---

3. LA MEILLEURE RAISON

Si vous n'avez pas de fixer tout l' E_NOTICE erreurs que vous pensez ne sont pas des erreurs, vous aurez probablement croître dans l'autosatisfaction, et commencent à ignorer les messages, et puis un jour, lorsqu'une erreur se produit, vous ne le remarquez pas.

Answer 2

Parce qu'un E_NOTICE indique une erreur.
PHP est tout simplement trop indulgent à l'appeler comme ça.

Par exemple, l'accès à une variable non définie produit un E_NOTICE.
Si cela arrive souvent, par exemple parce que vous n'êtes pas initialiser vos variables correctement, et que votre application est en train de lancer des avis de tous sur la place, comment allez-vous faire la différence entre une "variable qui fonctionne très bien non initialisé" et des moments où vous avez vraiment de la graisse doigts un nom de variable?

Cela peut déclencher un avis mais fonctionne comme prévu, de sorte que vous ignorer l'avis:

if ($_GET['foo']) ...

Cela, en revanche, va perdre la moitié de votre journée, tandis que d'ignorer l'avis et sont à essayer de comprendre pourquoi votre "bar() ne fonctionne pas":

$foo = bar();
if ($too) ...

Si vous n'avez pas "fixer" le premier cas, où la variable peut légitimement ne pas exister, vous ne pouvez pas utiliser de façon appropriée les avis d'attraper la faute dans le second cas.

Les avis sont là pour vous aider à déboguer votre application. Si vous les ignorez, vous ne faites que votre propre vie plus difficile.

Answer 3

Ce type d'erreurs est une bonne pratique à corriger, car ce sont ce que nous appelons «l'odeur de code», elles suggèrent un autre problème (comme des noms de variables mal tapés ou l'utilisation de variables non définies / une mauvaise utilisation des méthodes), ou elles causeront probablement des bogues dans le route lorsque vous réfléchissez / étendez le système.
Bien sûr, ce que j'ai dit ici n'est pas vrai à 100% des cas.

Answer 4

Ben je pense que c'est une excellente question. Vrai, c'est une bonne pratique à suivre pour tenter de corriger toutes les erreurs, même les non-fatal proches, à moins de faire de l'empêcherait de le concevoir (et donc souhaité) la fonctionnalité du système. En outre, tout niveau d'erreur indique que:

a) Il y a quelque chose de mal avec votre code, ou, b) Vous avez écrit le code qui est obsolète, ou d'avoir écrit le code qui est contraire instable et donc sujette à des effets secondaires.

Donc, je crois que si le calendrier et le budget d'un projet vous permet de le faire, vous devriez toujours s'efforcer de corriger les erreurs autant que possible, même si elles sont mineures en termes de leur impact sur le produit final.

Bien sûr, il y a un certain niveau d'acceptation du risque impliqué dans l'analyse coûts-avantages, de sorte qu'il peut très bien être le cas que les gestionnaires de surveiller les résultats du projet sont prêts à couvrir les éventuels coûts futurs de la fixation d'un problème connu contre le temps et des économies de coûts associés avec pas de fixation d'erreur. Le calcul fonctionne essentiellement de la façon dont vous pensez qu'il serait: Si le PV du coût de correction de l'erreur dans l'avenir est moins que l'argent économisé aujourd'hui, en ne fixant pas l'erreur, alors vous ne devriez pas le fixer. D'autre part, si les PV du coût de correction de l'erreur à l'avenir est plus important que l'argent économisé aujourd'hui, en ne fixant pas, alors il doit être corrigé aujourd'hui.

Qui, vraiment, est la justification pour (ou contre) la fixation d'une erreur aujourd'hui, quel que soit le niveau d'erreur.

Answer 5

Souvent, ils indiquent des erreurs logiques ou des fautes de frappe. Ils vous aideront à repérer les situations dans lesquelles vous avez mal saisi un nom de variable ou essayez d'utiliser une variable avant qu'il ne soit défini.

J'ai également vu des arguments selon lesquels il est plus efficace d'éviter les erreurs