So vermeiden Sie isset () und empty ()

Ich habe mehrere ältere Anwendungen, die viele "xyz is undefined" - und "undefined offset" -Nachrichten auslösen, wenn sie auf der E_NOTICE-Fehlerebene ausgeführt werden, da das Vorhandensein von Variablen nicht explizit mit isset()und consorts überprüft wird .

Ich denke darüber nach, sie durchzuarbeiten, um sie E_NOTICE-kompatibel zu machen, da Hinweise auf fehlende Variablen oder Offsets lebensrettend sein können, möglicherweise geringfügige Leistungsverbesserungen erzielt werden müssen und dies insgesamt sauberer ist.

Mir gefällt jedoch nicht, was das Zufügen von Hunderten von isset() empty()und array_key_exists()s mit meinem Code bewirkt. Es wird aufgebläht, weniger lesbar, ohne an Wert oder Bedeutung zu gewinnen.

Wie kann ich meinen Code ohne übermäßige Anzahl von Variablenprüfungen strukturieren und gleichzeitig E_NOTICE-kompatibel sein?

Für Interessenten habe ich dieses Thema zu einem kleinen Artikel erweitert, der die folgenden Informationen in einer etwas besser strukturierten Form enthält: Der endgültige Leitfaden für PHPs Isset und leer

IMHO sollten Sie darüber nachdenken, nicht nur die App "E_NOTICE kompatibel" zu machen, sondern das Ganze neu zu strukturieren. Mit Hunderten von Punkten in Ihrem Code , dass regelmäßig versucht Sounds inexistent Variablen wie ein eher schlecht strukturiertes Programm zu verwenden. Der Versuch, auf nicht vorhandene Variablen zuzugreifen, sollte niemals stattfinden. Andere Sprachen schrecken dies beim Kompilieren zurück. Die Tatsache, dass PHP es Ihnen ermöglicht, bedeutet nicht, dass Sie es tun sollten.

Diese Warnungen sollen Ihnen helfen, Sie nicht stören. Wenn Sie eine Warnung erhalten "Sie versuchen, mit etwas zu arbeiten, das es nicht gibt!" Ihre Reaktion sollte lauten: "Ups, mein Schlimmes, lassen Sie mich das so schnell wie möglich beheben." Wie sonst können Sie den Unterschied zwischen "Variablen, die gut und undefiniert funktionieren" und ehrlich falschem Code erkennen, der zu schwerwiegenden Fehlern führen kann ? Dies ist auch der Grund, warum Sie immer, immer mit einer Fehlerberichterstattung auf 11 entwickeln und Ihren Code so lange einstecken, bis kein einziger mehr vorhanden istNOTICEausgestellt wird. Das Deaktivieren der Fehlerberichterstattung gilt nur für Produktionsumgebungen, um Informationslecks zu vermeiden und eine bessere Benutzererfahrung auch bei fehlerhaftem Code zu erzielen.

Um näher darauf einzugehen:

Sie benötigen immer issetoder emptyirgendwo in Ihrem Code. Die einzige Möglichkeit, deren Auftreten zu reduzieren, besteht darin, Ihre Variablen ordnungsgemäß zu initialisieren. Je nach Situation gibt es verschiedene Möglichkeiten, dies zu tun:

Funktionsargumente:

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

Sie müssen nicht überprüfen, ob $baroder $bazsind sie in der Funktion festgelegt, da Sie sie nur festlegen. Sie müssen sich nur darum kümmern, ob ihr Wert zu trueoder false(oder was auch immer) ausgewertet wird .

Regelmäßige Variablen überall:

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

Initialisieren Sie Ihre Variablen oben in einem Codeblock, in dem Sie sie verwenden möchten. Dies löst das !issetProblem, stellt sicher, dass Ihre Variablen immer einen bekannten Standardwert haben, gibt dem Leser eine Vorstellung davon, wie der folgende Code funktioniert, und dient somit auch als eine Art Selbstdokumentation.

Arrays:

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

Auf die gleiche Weise wie oben initialisieren Sie das Array mit Standardwerten und überschreiben diese mit tatsächlichen Werten.

Nehmen wir in den verbleibenden Fällen eine Vorlage an, in der Sie Werte ausgeben, die möglicherweise von einem Controller festgelegt wurden oder nicht. Sie müssen lediglich Folgendes überprüfen:

<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>

Wenn Sie regelmäßig verwenden array_key_exists, sollten Sie bewerten, wofür Sie es verwenden. Das einzige Mal, dass es einen Unterschied macht, ist hier:

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

Wie oben erwähnt, müssen Sie bei ordnungsgemäßer Initialisierung Ihrer Variablen nicht überprüfen, ob der Schlüssel vorhanden ist oder nicht, da Sie wissen, dass dies der Fall ist. Wenn Sie das Array von einer externen Quelle , wenn es darum, wird der Wert wahrscheinlich nicht sein , nullsondern '', 0, '0', falseoder so ähnlich, dh einen Wert können Sie bewerten mit issetoder empty, abhängig von Ihrer Absicht. Wenn Sie regelmäßig einen Array Schlüssel gesetzt nullund wollen es alles bedeutet aber false, dh wenn in dem obigen Beispiel der unterschiedlichen Ergebnisse issetund array_key_existseinen Unterschied zu Ihrer Programmlogik zu machen, sollen Sie sich fragen , warum. Die bloße Existenz einer Variablen sollte nicht wichtig sein, nur ihr Wert sollte von Bedeutung sein. Wenn der Schlüssel ein true/ falseflag ist, verwenden Sietrueoder falsenicht null. Die einzige Ausnahme hiervon wären Bibliotheken von Drittanbietern, die nulletwas bedeuten wollen , aber da nulles in PHP so schwer zu erkennen ist, muss ich noch eine Bibliothek finden, die dies tut.

Schreiben Sie einfach eine Funktion dafür. Etwas wie:

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;
    }
}

die Sie als verwenden können

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

Machen Sie dasselbe für triviale Sachen wie get_number(), get_boolean(), get_array()und so weiter.

Ich glaube, eine der besten Möglichkeiten, mit diesem Problem umzugehen, besteht darin, über eine Klasse auf Werte von GET- und POST-Arrays (COOKIE, SESSION usw.) zuzugreifen.

Erstellen Sie für jedes dieser Arrays eine Klasse und deklarieren Sie __getund __setMethoden ( Überladung ). __getakzeptiert ein Argument, das der Name eines Werts ist. Diese Methode sollte diesen Wert im entsprechenden globalen Array überprüfen, indem entweder isset()oder verwendet wird empty()und der Wert zurückgegeben wird, falls vorhanden, oder null(oder ein anderer Standardwert) anderweitig.

Danach können Sie auf diese Weise sicher auf Array-Werte zugreifen: $POST->usernameund bei Bedarf eine Validierung durchführen, ohne isset()s oder empty()s zu verwenden. Wenn usernamedas entsprechende globale Array nicht vorhanden ist, nullwird es zurückgegeben, sodass keine Warnungen oder Benachrichtigungen generiert werden.

Es macht mir nichts aus, die array_key_exists()Funktion zu benutzen . Tatsächlich bevorzuge ich die Verwendung dieser spezifischen Funktion, anstatt mich auf Hack- Funktionen zu verlassen, die ihr Verhalten in Zukunft möglicherweise ändern, wie emptyundisset (durchgestrichen, um Anfälligkeiten zu vermeiden ).

Ich verwende jedoch eine einfache Funktion, die in dieser und einigen anderen Situationen beim Umgang mit Array-Indizes nützlich ist :

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;
}

Angenommen, Sie haben die folgenden Arrays:

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

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

Wie bekommt man den "Wert" aus den Arrays? Einfach:

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');

Wir haben bereits uni- und mehrdimensionale Arrays abgedeckt. Was können wir sonst noch tun?

Nehmen Sie zum Beispiel den folgenden Code:

$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';
}

Ziemlich langweilig, nicht wahr? Hier ist ein anderer Ansatz, der die Value()Funktion verwendet:

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

Nehmen SieRealIP() als zusätzliches Beispiel die Funktion für einen Test:

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

Ordentlich, was? ;)

Ich bin mit Dir hier. Aber PHP-Designer haben viel schlimmere Fehler gemacht. Ohne eine benutzerdefinierte Funktion für das Lesen von Werten zu definieren, führt kein Weg daran vorbei.

Ich benutze diese Funktionen

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

Beispiele

$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";
}

Willkommen beim Null-Koaleszenz-Operator (PHP> = 7.0.1):

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

PHP sagt:

Der Null-Koaleszenz-Operator (??) wurde als syntaktischer Zucker für den allgemeinen Fall hinzugefügt, dass in Verbindung mit isset () ein Ternär verwendet werden muss. Es gibt seinen ersten Operanden zurück, wenn er existiert und nicht NULL ist. Andernfalls wird der zweite Operand zurückgegeben.

Erstellen Sie eine Funktion, die zurückgibt, falsewenn sie nicht festgelegt ist, und, falls angegeben, falseleer ist. Wenn gültig, wird die Variable zurückgegeben. Sie können weitere Optionen hinzufügen, wie im folgenden Code dargestellt:

<?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"];
}
?>

Ich bin mir nicht sicher, wie Sie die Lesbarkeit definieren, aber die ordnungsgemäße Verwendung der Blöcke empty (), isset () und try / throw / catch ist für den gesamten Prozess ziemlich wichtig. Wenn Ihre E_NOTICE von $ _GET oder $ _POST stammt, sollten sie zusammen mit allen anderen Sicherheitsüberprüfungen, die diese Daten bestehen müssen, gegen empty () geprüft werden. Wenn es aus externen Feeds oder Bibliotheken stammt, sollte es in try / catch eingeschlossen werden. Wenn es aus der Datenbank stammt, sollte $ db_num_rows () oder ein gleichwertiges Element überprüft werden. Wenn es von internen Variablen stammt, sollten sie ordnungsgemäß initialisiert werden. Diese Arten von Benachrichtigungen stammen häufig aus der Zuweisung einer neuen Variablen zur Rückgabe einer Funktion, die bei einem Fehler FALSE zurückgibt. Diese sollten in einen Test eingeschlossen werden, der im Fehlerfall Sie können der Variablen entweder einen akzeptablen Standardwert zuweisen, den der Code verarbeiten kann, oder eine Ausnahme auslösen, die der Code verarbeiten kann. Diese Dinge verlängern den Code, fügen zusätzliche Blöcke hinzu und fügen zusätzliche Tests hinzu, aber ich stimme Ihnen nicht darin zu, dass sie auf jeden Fall einen zusätzlichen Mehrwert bieten.

Software wird nicht auf magische Weise von der Gnade Gottes ausgeführt. Wenn Sie etwas erwarten, das fehlt, müssen Sie es richtig handhaben.

Wenn Sie es ignorieren, schaffen Sie wahrscheinlich Sicherheitslücken in Ihren Anwendungen. In statischen Sprachen ist der Zugriff auf eine nicht definierte Variable einfach nicht möglich. Es wird Ihre Anwendung nicht einfach kompilieren oder zum Absturz bringen, wenn sie null ist.

Darüber hinaus ist Ihre Anwendung nicht mehr zu warten, und Sie werden verrückt, wenn unerwartete Dinge passieren. Sprachstrenge ist ein Muss und PHP ist von Natur aus in so vielen Aspekten falsch. Es macht Sie zu einem schlechten Programmierer, wenn Sie sich dessen nicht bewusst sind.

Was ist mit dem @Operator?

Beispielsweise:

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

Sie können sagen, dass dies schlecht ist, weil Sie keine Kontrolle darüber haben, was "innerhalb" von $ foo passiert (wenn es sich beispielsweise um einen Funktionsaufruf handelt, der einen PHP-Fehler enthält). Wenn Sie diese Technik jedoch nur für Variablen verwenden, entspricht dies:

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