Comment éviter isset () et empty ()

J'ai plusieurs applications plus anciennes qui lancent beaucoup de messages "xyz is undefined" et "undefined offset" lors de l'exécution sur le niveau d'erreur E_NOTICE, car l'existence de variables n'est pas explicitement vérifiée à l'aide de isset()et consorts.

J'envisage de travailler avec eux pour les rendre compatibles E_NOTICE, car les avis sur les variables ou les décalages manquants peuvent sauver des vies, il peut y avoir des améliorations mineures des performances à gagner, et c'est globalement la manière la plus propre.

Cependant, je n'aime pas ce qu'inflige des centaines de isset() empty()et array_key_exists()s à mon code. Il se gonfle, devient moins lisible, sans rien gagner en valeur ou en sens.

Comment structurer mon code sans excès de contrôles de variables, tout en étant compatible E_NOTICE?

Pour ceux qui sont intéressés, j'ai développé ce sujet dans un petit article, qui fournit les informations ci-dessous sous une forme un peu mieux structurée: The Definitive Guide To PHP's isset And empty

IMHO, vous devriez penser non seulement à rendre l'application "E_NOTICE compatible", mais à restructurer le tout. Avoir des centaines de points dans votre code qui essaient régulièrement d'utiliser des variables inexistantes ressemble à un programme plutôt mal structuré. Essayer d'accéder à des variables inexistantes ne devrait jamais arriver, d'autres langages hésitent à cela au moment de la compilation. Le fait que PHP vous permette de le faire ne signifie pas que vous devriez le faire.

Ces avertissements sont là pour vous aider , pas pour vous ennuyer. Si vous recevez un avertissement "Vous essayez de travailler avec quelque chose qui n'existe pas!" , votre réaction devrait être "Oups, mon mauvais, laissez-moi résoudre ce problème dès que possible." Sinon, comment allez-vous faire la différence entre "des variables qui fonctionnent très bien et non définies" et un code honnêtement erroné qui peut conduire à de graves erreurs ? C'est aussi la raison pour laquelle vous développez toujours, toujours avec le rapport d'erreur passé à 11 et continuez à brancher votre code jusqu'à ce que pas un seulNOTICEest émis. La désactivation des rapports d'erreurs est réservée aux environnements de production, afin d'éviter les fuites d'informations et de fournir une meilleure expérience utilisateur, même en cas de code bogué.

Élaborer:

Vous aurez toujours besoin issetou emptyquelque part dans votre code, le seul moyen de réduire leur occurrence est d'initialiser correctement vos variables. Selon la situation, il existe différentes manières de procéder:

Arguments de fonction:

function foo ($bar, $baz = null) { ... }

Il n'est pas nécessaire de vérifier si $barou $bazsont définis à l'intérieur de la fonction car vous venez de les définir, tout ce dont vous avez besoin est de savoir si leur valeur est évaluée à trueou false(ou quoi que ce soit d'autre).

Variables régulières n'importe où:

$foo = null;
$bar = $baz = 'default value';

Initialisez vos variables en haut d'un bloc de code dans lequel vous allez les utiliser. Cela résout le !issetproblème, garantit que vos variables ont toujours une valeur par défaut connue, donne au lecteur une idée de ce sur quoi le code suivant fonctionnera et sert ainsi également de sorte d'auto-documentation.

Tableaux:

$defaults = array('foo' => false, 'bar' => true, 'baz' => 'default value');
$values = array_merge($defaults, $incoming_array);

La même chose que ci-dessus, vous initialisez le tableau avec les valeurs par défaut et les écrasez par les valeurs réelles.

Dans les cas restants, disons un modèle où vous produisez des valeurs qui peuvent ou non être définies par un contrôleur, il vous suffira de vérifier:

<table>
    <?php if (!empty($foo) && is_array($foo)) : ?>
        <?php foreach ($foo as $bar) : ?>
            <tr>...</tr>
        <?php endforeach; ?>
    <?php else : ?>
        <tr><td>No Foo!</td></tr>
    <?php endif; ?>
</table>

Si vous vous retrouvez à utiliser régulièrement array_key_exists, vous devriez évaluer à quoi vous l'utilisez. Le seul moment où cela fait une différence, c'est ici:

$array = array('key' => null);
isset($array['key']); // false
array_key_exists('key', $array); // true

Comme indiqué ci-dessus cependant, si vous initialisez correctement vos variables, vous n'avez pas besoin de vérifier si la clé existe ou non, car vous le savez. Si vous obtenez le tableau à partir d' une source externe, la valeur sera très probablement pas nullmais '', 0, '0', falseou quelque chose comme ça, soit une valeur que vous pouvez évaluer avec issetou empty, selon votre intention. Si vous définissez régulièrement une clé de tableau sur nullet que vous voulez qu'elle ait une signification autre que false, c'est-à-dire si, dans l'exemple ci-dessus, les résultats différents de issetet array_key_existsfont une différence dans la logique de votre programme, vous devriez vous demander pourquoi. La simple existence d'une variable ne devrait pas être importante, seule sa valeur devrait être importante. Si la clé est un indicateur true/ false, utiliseztrueou falsenon null. La seule exception à cela serait les bibliothèques tierces qui veulent nullsignifier quelque chose, mais comme nullc'est si difficile à détecter en PHP, je n'ai pas encore trouvé de bibliothèque qui le fasse.

Écrivez simplement une fonction pour cela. Quelque chose comme:

function get_string($array, $index, $default = null) {
    if (isset($array[$index]) && strlen($value = trim($array[$index])) > 0) {
        return get_magic_quotes_gpc() ? stripslashes($value) : $value;
    } else {
        return $default;
    }
}

que vous pouvez utiliser comme

$username = get_string($_POST, 'username');

Faites la même chose pour des choses triviales comme get_number(), get_boolean(), get_array()et ainsi de suite.

Je pense que l'un des meilleurs moyens de résoudre ce problème est d'accéder aux valeurs des tableaux GET et POST (COOKIE, SESSION, etc.) via une classe.

Créez une classe pour chacun de ces tableaux et déclarez les méthodes __getet __set( surcharge ). __getaccepte un argument qui sera le nom d'une valeur. Cette méthode doit vérifier cette valeur dans le tableau global correspondant, en utilisant isset()ou empty()et renvoyer la valeur si elle existe ou null(ou une autre valeur par défaut) sinon.

Après cela, vous pouvez accéder en toute confiance aux valeurs du tableau de cette manière: $POST->usernameet faire toute validation si nécessaire sans utiliser de isset()s ou de empty()s. Si usernamen'existe pas dans le tableau global correspondant, alors nullsera retourné, donc aucun avertissement ou avis ne sera généré.

Cela ne me dérange pas d'utiliser la array_key_exists()fonction. En fait, je préfère utiliser cette fonction spécifique plutôt que de me fier à des fonctions de piratage qui peuvent changer leur comportement à l'avenir comme emptyetisset (barré pour éviter les susceptibilités ).

Cependant, j'utilise une fonction simple qui est utile dans ce cas, et dans d'autres situations pour traiter les index de tableau :

function Value($array, $key, $default = false)
{
    if (is_array($array) === true)
    {
        settype($key, 'array');

        foreach ($key as $value)
        {
            if (array_key_exists($value, $array) === false)
            {
                return $default;
            }

            $array = $array[$value];
        }

        return $array;
    }

    return $default;
}

Disons que vous avez les tableaux suivants:

$arr1 = array
(
    'xyz' => 'value'
);

$arr2 = array
(
    'x' => array
    (
        'y' => array
        (
            'z' => 'value',
        ),
    ),
);

Comment obtenez-vous la «valeur» des tableaux? Facile:

Value($arr1, 'xyz', 'returns this if the index does not exist');
Value($arr2, array('x', 'y', 'z'), 'returns this if the index does not exist');

Nous avons déjà couvert des tableaux unidimensionnels et multidimensionnels, que pouvons-nous faire d'autre?

Prenez le morceau de code suivant par exemple:

$url = '/programming/1960509';
$domain = parse_url($url);

if (is_array($domain) === true)
{
    if (array_key_exists('host', $domain) === true)
    {
        $domain = $domain['host'];
    }

    else
    {
        $domain = 'N/A';
    }
}
else
{
    $domain = 'N/A';
}

Assez ennuyeux n'est-ce pas? Voici une autre approche utilisant la Value()fonction:

$url = '/programming/1960509';
$domain = Value(parse_url($url), 'host', 'N/A');

Comme exemple supplémentaire, prenez la RealIP()fonction pour un test:

$ip = Value($_SERVER, 'HTTP_CLIENT_IP', Value($_SERVER, 'HTTP_X_FORWARDED_FOR', Value($_SERVER, 'REMOTE_ADDR')));

Neat, hein? ;)

Je suis là avec toi. Mais les concepteurs PHP ont fait des erreurs bien plus pires que cela. À moins de définir une fonction personnalisée pour toute lecture de valeur, il n'y a aucun moyen de contourner cela.

J'utilise ces fonctions

function load(&$var) { return isset($var) ? $var : null; }
function POST($var) { return isset($_POST[$var]) ? $_POST[$var] : null; }

Exemples

$y = load($x); // null, no notice

// this attitude is both readable and comfortable
if($login=POST("login") and $pass=POST("pass")) { // really =, not ==
  // executes only if both login and pass were in POST
  // stored in $login and $pass variables
  $authorized = $login=="root" && md5($pass)=="f65b2a087755c68586568531ad8288b4";
}

Bienvenue dans l'opérateur de fusion nul (PHP> = 7.0.1):

$field = $_GET['field'] ?? null;

PHP dit:

L'opérateur de fusion nul (??) a été ajouté comme sucre syntaxique pour le cas courant de besoin d'utiliser un ternaire en conjonction avec isset (). Il renvoie son premier opérande s'il existe et n'est pas NULL; sinon, il renvoie son deuxième opérande.

Créez une fonction qui retourne falsesi elle n'est pas définie et, si elle est spécifiée, falsesi elle est vide. S'il est valide, il renvoie la variable. Vous pouvez ajouter plus d'options comme indiqué dans le code ci-dessous:

<?php
function isset_globals($method, $name, $option = "") {
    if (isset($method[$name])) {    // Check if such a variable
        if ($option === "empty" && empty($method[$name])) { return false; } // Check if empty 
        if ($option === "stringLength" && strlen($method[$name])) { return strlen($method[$name]); }    // Check length of string -- used when checking length of textareas
        return ($method[$name]);
    } else { return false; }
}

if (!isset_globals("$_post", "input_name", "empty")) {
    echo "invalid";
} else {
    /* You are safe to access the variable without worrying about errors! */
    echo "you uploaded: " . $_POST["input_name"];
}
?>

Le logiciel ne fonctionne pas comme par magie par la grâce de Dieu. Si vous attendez quelque chose qui manque, vous devez le gérer correctement.

Si vous l'ignorez, vous créez probablement des failles de sécurité dans vos applications. Dans les langages statiques, accéder à une variable non définie n'est tout simplement pas possible. Il ne compilera ni ne plantera simplement votre application si elle est nulle.

De plus, cela rend votre application impossible à gérer et vous allez devenir fou lorsque des choses inattendues se produisent. La rigueur du langage est un must et PHP, de par sa conception, est faux à bien des égards. Cela fera de vous un mauvais programmeur si vous n'êtes pas au courant.

Je ne sais pas quelle est votre définition de la lisibilité, mais l'utilisation correcte des blocs empty (), isset () et try / throw / catch est assez importante pour l'ensemble du processus.

Si votre E_NOTICE provient de $ _GET ou $ _POST, alors ils doivent être vérifiés par rapport à empty () avec tous les autres contrôles de sécurité que ces données doivent passer.

S'il provient de sources externes ou de bibliothèques, il doit être encapsulé dans try / catch.

S'il vient de la base de données, $ db_num_rows () ou son équivalent doit être vérifié.

Si cela provient de variables internes, elles doivent être correctement initialisées. Souvent, ces types d'avis proviennent de l'affectation d'une nouvelle variable au retour d'une fonction qui renvoie FALSE en cas d'échec. Ceux-ci devraient être enveloppés dans un test qui, en cas d'échec, peut soit affecter à la variable une valeur par défaut acceptable que le code peut gérer, soit lever une exception que le code peut gérer.

Ces choses allongent le code, ajoutent des blocs supplémentaires et ajoutent des tests supplémentaires, mais je ne suis pas d'accord avec vous en ce sens que je pense qu'ils ajoutent certainement une valeur supplémentaire.

Qu'en est-il de l'utilisation de l' @opérateur?

Par exemple:

if(@$foo) { /* Do something */ }

Vous pouvez dire que c'est mauvais parce que vous n'avez aucun contrôle sur ce qui se passe "à l'intérieur" de $ foo (si c'est un appel de fonction qui contient une erreur PHP par exemple), mais si vous n'utilisez cette technique que pour les variables, c'est équivalent à:

if(isset($foo) && $foo) { /* ... */ }