Why I Avoid Using Empty() in PHP? A Closer Look
The author critiques the PHP function empty() for its misleading behavior, recommending strict comparisons (===) for accurate checks to avoid confusion and bugs, especially for new developers.
Read original article
The article discusses the author's reservations about using the PHP function empty(). While it appears to be a straightforward way to check if a variable is empty, its behavior is more complex than it seems. The function considers various values, including 0, "0", and false, as empty, which can lead to unexpected results in code, particularly in production environments. For instance, if a JSON response includes a distance value of "0.0", using empty() would incorrectly indicate that the distance is not set, even though it is a valid number. The author advocates for using strict comparisons (===) instead of empty() to ensure that only specific cases are evaluated, thus avoiding potential bugs. The misleading name of empty() can confuse developers, especially those new to PHP, leading to incorrect assumptions about its functionality. The article concludes by emphasizing the importance of understanding PHP functions thoroughly and opting for precise checks to enhance code reliability.
- The PHP function empty() can lead to unexpected behavior by treating values like 0 and false as empty.
- Using strict comparisons (===) is recommended for more accurate value checks.
- Misleading function names can cause confusion and bugs, especially for new developers.
- Understanding the nuances of PHP functions is crucial for writing robust code.
- Precise checks can prevent issues in production environments.
Related
The many faces of undefined in JavaScript
JavaScript's handling of undefined values, including null and falsy values, can confuse developers. TypeScript introduces nuances with function arguments and void type. Recommendations suggest treating undefined as null to avoid issues.
Optimizing JavaScript for Fun and for Profit
Optimizing JavaScript code for performance involves benchmarking, avoiding unnecessary work, string comparisons, and diverse object shapes. JavaScript engines optimize based on object shapes, impacting array/object methods and indirection. Creating objects with the same shape improves optimization, cautioning against slower functional programming methods. Costs of indirection like proxy objects and function calls affect performance. Code examples and benchmarks demonstrate optimization variances.
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
Don't use null objects for error handling
The article critiques using null objects for error handling in programming, arguing it misleads users and propagates errors. It advocates for immediate error handling and context-based strategies instead.
Why Not Comments
The article emphasizes the significance of "why not" comments in programming, highlighting their role in explaining decision-making and trade-offs that identifiers alone cannot convey, while questioning self-documentation limits.
11 commentsUse 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?
The value that empty() provides in PHP is similar to a null coalescing operator in many languages:
if (empty($foo->bar['baz'])) {
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.
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.
Dynamic programming languages usually have some arbitrary rules about what X is treated true or false in
if(X) (…}
if(f(X)) {}
https://www.reddit.com/r/lolphp
Here the top posts of all time:
Related
The many faces of undefined in JavaScript
JavaScript's handling of undefined values, including null and falsy values, can confuse developers. TypeScript introduces nuances with function arguments and void type. Recommendations suggest treating undefined as null to avoid issues.
Optimizing JavaScript for Fun and for Profit
Optimizing JavaScript code for performance involves benchmarking, avoiding unnecessary work, string comparisons, and diverse object shapes. JavaScript engines optimize based on object shapes, impacting array/object methods and indirection. Creating objects with the same shape improves optimization, cautioning against slower functional programming methods. Costs of indirection like proxy objects and function calls affect performance. Code examples and benchmarks demonstrate optimization variances.
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
Don't use null objects for error handling
The article critiques using null objects for error handling in programming, arguing it misleads users and propagates errors. It advocates for immediate error handling and context-based strategies instead.
Why Not Comments
The article emphasizes the significance of "why not" comments in programming, highlighting their role in explaining decision-making and trade-offs that identifiers alone cannot convey, while questioning self-documentation limits.