Czy używanie funkcji empty() w warunkach jest konieczne? Będzie błędem, jeśli napiszę warunek bez empty()? Bo jedno i drugie rozwiązanie działa chyba identycznie...

Nie dziala identycznie. jesli $var nie jest zadeklarowana to poleci ci NOTICE w drugim wypadku

A gdy mam pewność, iż zmienna $var jest zadeklarowana (np. jest zwrócona przez funkcję jako konkretny typ wartości), to mogę chyba [zawsze] zapisać drugim sposobem (bez empty())?

Ja nie jestem zwolennikiem zapisywania w taki sposób warunków, gdy $var nie jest boolem.

Wolę tak:

[PHP] pobierz, plaintext 
if ($var !== '') {/* dla string */}
if ($var !== 0) {/* dla int */}
if ($var !== null) {/* dla nullable */}
if ($var) {/* dla bool */}
[PHP] pobierz, plaintext 

empty() używam tylko z tablicami.

Nasunęło mi się jeszcze jedno pytanie. A jak postępować, gdy zwracam np. z repozytorium (bazy danych) obiekt lub null (?object)? Ewentualnie wartość typu np. string lub null (?string)... Wtedy chyba powinienem użyć: if (!empty($var)) {}

No wtedy tym bardziej nie powinienes uzywac empty. Przeciez srting moze byc pustym tekstem a to moze byc ok.

Wtedy masz uzyc !== null

Co do sprawdzania istnienia obiektów. Dla zwracanych obiektów (typu ?object) rozumiem, że ma być [zawsze] tak samo: if ($object !== null) {}. Zmylił mnie przykład z dokumentacji, gdzie przy użyciu empty() sprawdzali, czy obiekt został utworzony. Tu też zamiast empty($object) powinno się użyć raczej isset($object) i dalej is_object($object)... Bo dla np. obiektów formularzy, które mogą zwracać pusty string '' (gdy przesłany) lub null (gdy nieprzesłany), funkcja !empty() może mieć zastosowanie, gdy chcemy sprawdzić, czy jakakolwiek wartość została podana. Choć z moich obserwacji (w Symfony) puste pole formularza (z obiektu formularza) zwraca zawsze null (czy przesłany bądź nieprzesłany). I tu też chyba powinienem przyrównywać do null...

Jeśli zwracany obiekt to wolę


to tak dla pewności że jest tu czego oczekuję. Można też null !== $obj jeśli return z metody jest typehinted

Co do porównywania null !== $var jest coś takiego jak is_null($var).

Poza tym, dobrze zapoznać się z tabelką na https://www.php.net/manual/en/types.comparisons.php żeby nie mieć wątpliwości co daje jakie wyniki.

Cieszyłbym się, gdyby zaczęli sprzątać PHP i m.in. usunęli is_null(). Nie lubię, gdy jedną prostą rzecz można zrobić na kilka identycznych sposobów.

To idąc dalej takim tokiem rozumowania można całkowicie dużo funkcji usunąć skoro jest empty oraz inne nowe operatory. Ja tam bardzo lubię is_null. A wracając do tematu. Zainstaluj sobie jakieś narzędzia typu cs fixer, ustaw zbiór własnych reguł (w tym tutaj yoda style) i masz z głowy zajmowanie się pierdołami.

No i tak wg mnie powinni zrobić - zacząć usuwać. Dzisiaj już się inaczej projektuje języki, zobacz sobie takiego Swifta, albo nawet niemłodego już Pythona. Wiem, że mogę zacząć "ignorować" pewne możliwości, ale dla jakiejś tam perfekcjonistycznej części mnie to jest niedogodność

empty() nigdy nie lubiłem, a w PHP <= 5.4 ta funkcja była jeszcze bardziej irytująca, bo nie pozwalała używać wyrażeń, czyli np. to wyrzucało błąd:

[PHP] pobierz, plaintext 
$foo = empty(1 + 0);
[PHP] pobierz, plaintext 

Dobrze zaprojektowany język nie ma takich trudnych do zapamiętania nieścisłości, wszystko powinno być klarowne zamiast kazać nam "pamiętać" o swoich dziwactwach. Dlatego jestem za sprzątaniem. Osobiście prawie nigdy nie używam is_null(), tylko $foo === null. Jedyny wyjątek to array_filter($foo, 'is_null'), array_map('is_foo', $foo) lub jakieś inne stringowe callbacki. Ale nadal bym wolał, żeby tego nie było