Why I avoid using empty() in PHP? A Closer Look

https://azizdev.medium.com/why-i-avoid-using-empty-in-php-a-closer-look-12765e87542c

by mooreds • 2 years ago

16 30 2 years ago

azizdev.medium.com

While I appreciate the availability of empty(), I appreciate this article as it clearly states why we should use stricter comparisons. Avoid mistakes, and conserve resources.

chiefalchemist• 2 years ago

It's not a matter of avoiding empty(). It's a matter of only using it when it's the correct tool. The examples were examples of someone using a screwdriver when they needed a hammer. That's not the screwdriver's fault.

croes4• 2 years ago

If the screwdriver is called hammer I would blame the manufacturer.

An int with the value 0 isn't empty.

Cyberdog5• 2 years ago

What value would an empty int have, then?

chx• 2 years ago

You are using comparison like this after a float cast?? That's a paddlin'.

veonik• 2 years ago

Yep, that whole example after the float cast is bit silly. After the cast, the value can never be an empty string, or null. Not to mention, comparing a floating point value to an arbitrary, literal value (of zero in this case) is potentially problematic [1].

[1]: See the warning on this page, this applies to all languages with floating point arithmetic. https://www.php.net/manual/en/language.types.float.php

Faelian2• 2 years ago

Do you guys know if `!isset()` is a good alternative ? Or if it also has some shortcomings ?

handelaar• 2 years ago

isset($var) will return false if you have deliberately set $var === NULL

Otherwise more or less fine?

The whole OP here is a longwinded way of observing that several built-in PHP functions don't know anything about types. You can't use switch() as it's usually documented either, for example, because that ignores types too.

There are ways around all these things, of course. PHP that doesn't suck is kind of the norm these days. Just stay the hell away from Wordpress

Cyberdog5• 2 years ago

How can WordPress be so prominent and have so much money behind it and still have such garbage code? Are there giant companies still running PHP 4 server farms that need it to continue to be coded to 2003 standards? Is it some government op to ensure a good deal of the sites on the web are easily-hackable? Someone explain this to me.

Shadowmist• 2 years ago

Scroll below the article for another article about isset.

ddtaylor2• 2 years ago

isset() is a great additional tool and has most of the same properties of empty(), except it deals explicitly with null. Most importantly it doesn't produce exceptions, errors, warnings or notices when keys are missing or you attempt to de-reference null.

cynicalsecurity2• 2 years ago

Alternative to what exactly? Both empty(), isset() and implicit casting to boolean are useful tools for their specific purposes.

joshstrange3• 2 years ago

This entire post is dedicated to using the wrong tool for the job…

Use isset if you want to see if the variable is set, you should never be casting client input unless it’s coming from query params (or form post I guess but at that point use JSON).

“empty” is a useful tool, provided you take into account things like “is this allowed to be 0/empty-string/etc”.

Lastly:

After a lengthy debugging session, we realized that empty() was treating 0 as "empty", causing our validation to fail unexpectedly.

Lengthy? To notice an empty check failing? Look, the codebase I work on has its warts, all older codebases do, but unless you have no XDebug, forgot how to log to file or echo to the client, and/or aren’t capable of searching a codebase for the error you got and tracing it back from there then I can’t believe that would be a “Lengthy” process to track down. Even if you are returning a generic error to the client, surely you are logging the real error to a log somewhere?

Szpadel• 2 years ago

it's not always that straight forward to connect xdebug to where you need it, especially if that is triggered by some API call from external uncontrolled system. if that error could just trigger some generic error like product/entry/item is invalid so you would have no idea with exact condition failed. finally there in e-commerce offer there are import processes that get thousands of products in single batch, logging will get very messy and getting to that one product that had issue might take some time in each run

we had some errors that were happening to only one client and noone could reproduce that.

croes4• 2 years ago

Maybe don't call a screwdriver a hammer.

I don't know enough PHP.

Does isset return true or false if I set a string variable to "" before I call isset?

joshstrange3• 2 years ago

`isset` will return true/false and it will only return false if the value is null (never initialized or specifically set to null).

Example:

    $myVar = null;
    var_dump(isset($myVar)); // false
    $myVar = '';
    var_dump(isset($myVar)); // true
    $myVar = '0';
    var_dump(isset($myVar)); // true
    $myVar = 0;
    var_dump(isset($myVar)); // true

If you have a property on a class that was never given a value it will also return `false`:

    class MyClass {
        public $myProp;
        
        function myFunction() {
            var_dump(isset($this->myProp)); // false
        }
    }

ericpp• 2 years ago

It's a common mistake that newcomers to the language make. You assume empty is an empty string check when it's really a falsy check that is equivalent to: (!isset($var) || !$var)

cies• 2 years ago

There's an entire subreddit making fun of PHP quirks:

https://www.reddit.com/r/lolphp

Here the top posts of all time:

https://www.reddit.com/r/lolphp/top/?t=all

ddtaylor2• 2 years ago

Thankfully others have correctly identified this is not a real use case for empty and someone wrote an entire article about it.

The value that empty() provides in PHP is similar to a null coalescing operator in many languages:

    if (empty($foo->bar['baz'])) {

In this line of code all of the above can be missing. $foo can be an undefined variable, let alone one that has a value, and likewise all of the members, arrays, keys, etc. can also be missing. It does not throw an exception or trigger any warnings/errors to be logged, since, well, that's the purpose of empty.

If you want similar-ish behavior but you're not interested in the problems associated with the empty semantics, use isset() as it has the same properties for non-existent keys.

goshx• 2 years ago

In both examples, to check distance and price, the author should have simply used is_numeric()

PaulHoule• 2 years ago

All programming languages have some problems in this department. Some lisps for instance use the empty list nil for false, others have a distinct #f value. Each of those choices has strengths and weaknesses.

Dynamic programming languages usually have some arbitrary rules about what X is treated true or false in

  if(X) (…}

whatever rules are used are what you want almost always except for the times that they aren’t. A strongly typed language like Java will require X to be a boolean which now puts a load on the programmer to choose some f such that

   if(f(X)) {}

which could be correct every time in principle but a small increase in cognitive load is certain while most likely the f you choose (inclusive of your choice and it’s action) will do the right thing almost all the time except when it doesn’t. So I wouldn’t laugh at any particular programming language’s almost-right choice for ‘casting’ any to boolean because people are going to screw it up in any programming language.

Cyberdog5• 2 years ago

In PHP, as in other languages, numeric types that aren't ints should be avoided as much as possible. If you don't know why, smarter people can explain it, but the basics are that the binary nature of computers (every value is 0, 1, or a combination thereof) doesn't really work for reflecting decimal values without some level of fakery.

When working with things like money amounts, lengths, etc, store values as ints of the smallest denominator you support. For example, store $1.23 as 123 cents, or 4.567 meters as 4567 tenths of a centimeter. If you want to still allow the user to be able to, for example, enter a price as 1.23, multiply by 100 on input (like `$priceInCents = round($_POST['price'] * 100);`) and divide by 100 when displaying the value(`number_format($priceInCents / 100, 2)`), but keep it as an int all the way in between.

In terms of PHP, this also makes empty() a lot more predictable, because once a value is cast as int, the only time empty() will return true is if it is zero - or you could explicitly code `$priceInCents === 0` and have the exact same result.

Why I avoid using empty() in PHP? A Closer Look

Related Stories