<!–texy–>Mě jako cesta do pekel příjde spíš kód plný kódu

<code>(isset($arr['prvek'])?$arr['prvek']:NULL)</code>

která stejný význam jako

<code>$arr['prvek']</code>

Ale to už se opakuju.

Rozdíl proměnná vs. prvek vidím v tom, že při deklaraci fce můžu neexistujícím proměnným přiřadit defaultní hodnotu

<code>function fce($prom = null) { }</code>

u prvků polí nikoliv. Jedině na začátku každé funkce přijímající pole, které může obsahovat různou množinu prvků, nejprve všechny používané prvky otestovat na existenci a případně jim dát NULL (tím si vymezím co všechno se může v poli předávat). To mi přijde jako jediné možné řešení, ostatní, kdy se neustále v kódu issetuju mi přijde cesta do pekel. Trochu pitomé to je, když se může to pole různě zanořovat.

Jinak budu nejspíš používat [22] vypnutí E_NOTICE pomocí error_reporting() asi.

<!–texy–>[17] K tomu asociativnímu poli – měl jsem namysli ten případ, kdy se kód programu příliš spoléhá na to, že existují konkrétní položky v poli. Pokud by PHP v okamžiku, kdy k těmto položkám program přistupuje (a ony neexistují), neházelo NOTICE ale "tiše" vrátilo NULL, mnohem hůře by se na chybu přišlo. Už mnohokrát jsem byl nucen hledat chybu v cizím robustním kódu a věřtě mi, že v takových chvílích jsem za NOTICE velmi rád.

[18] Samozřejmě je to otázka přístupu. Já ve svých myšlenkách nerozlišuji proměnnou od prvku pole. Zkrátka nevidím důvod, proč by PHP v jednom případě mělo k problému přistupovat nějak a v druhém zase jinak.

A právě to isset mě od překlepů často zachrání, už jenom proto, že ten index zkrátka píšu dvakrát :) Pokud je někdo líný to ošetření dělat, ať si opravdu napíše tu pomocnou funkci. Mimochodem – násilím potlačovat chybový výpis přes @ je podle mě ve většině případů cesta do pekel.

<!–texy–>[20] Kód, který má být schopný fungovat všude, může na začátku zavolat error_reporting() a E_NOTICE vypnout. Zavináč opravdu není dobré řešení.

[21] Zkrácený ternární operátor ($a ?: "") už je v PHP 5.3, ale nikoliv ve významu ifsetor() – na nenastavené proměnný také vyhodí E_NOTICE.

<!–texy–>[20] počítej s tím, že tato vlastnost PHP se nezmění. Možná se objeví nějaký ifsetor nebo zkrácený ternární operátor, do té doby doporučuji napsat vlastní funkci (jen v komentářích jich bylo zmíněno několik). Dělám to tak taky.

Ještě tu nebyla zmíněna věc, že jedna věc je psaní kódu, a druhá věc jsou jeho pozdější úpravy. Těm se obvykle věnuje víc úsilí než samotnému psaní, navíc často probíhá s časovým odsupem. Nezavař si do budoucna!

Až po čase šáhneš do kódu, bude ti důležitým pomocníkem výpis error_reporting(E_ALL). Pokud error reporting neporadí, nastoupí zdlouhavé hledání chyby, na jehož konci nezřídkakdy bude řádek "utlumený" zavináčem. Právě proto radím zavináče nepoužívat. Nedají se totiž narozdíl od úrovní error_reporting snadno vypínat a zapínat.

Zároveň doporučuji psát kód tak, aby nevyhazoval E_NOTICE, protože když zapnu reportování kvůli hledání chyby, je nepohodlné ji hledat utopenou v hromadě "nechyb".

<!–texy–>Jakube, díky za pěkné přeformulování toho co mě vrtalo v hlavě. Když se teda znovu vyjádřím..

-> Chci se spolehnout na výchozí hodnotu (NULL) neiniciovaného prvku pole.

-> Současné řešení je nevhodné, v zásadě nic neřeší, pouze mě otravuje (vypisováním E_NOTICE).

-> Dokud bude php tyto E_NOTICE vypisovat a nebude implemetované nějaké přijatelné řešení (např. zmíněné ifsetor), v kódu který má být schopný fungovat všude, budu nejspíš kacířsky používat @zavináč.

Jinak asi E_NOTICE vypínám budu psát elegantní kód :)

<!–texy–>[17] v zásadě máš pravdu.

Tohle sou možnosti, který můžes použít, seřazeno podle mě od nejvíc košér po nejmíň:
1. používat isset() (takto to použití asi vývojáři php zamýšleli, aby nejméně dvojitým zapsáním proměnné byla eliminována pravděpodobnost překlepu, bohužel pro programátora na psaní nejvíce ukecané.)
2. napsat si vlastní fci, která vrací null při neexistenci. (pokud se nebojíte překlepů a nechcete vypínat E_NOTICE)
3. používat @ na potlačení chyb, tam kde chcete.
4. vypnout zobrazování E_NOTICE.

<!–texy–>[16] Práce s neinicializovaným polem je samozřejmě nevhodná. Ale práce s neinicializovanými prvky inicializovaného pole je bezpečná a spolehnutí se na výchozí hodnotu neinicializovaného prvku často dává velmi dobrý smysl. Samozřejmě to je zkratka, ale "značená", abych tak řekl

Kód (isset($_GET["seerch"]) ? $_GET["seerch"] : "") tě od překlepů stejně jako samotné $_GET["seerch"] nijak neuchrání. Mohl bys rozebrat "přijde neočekávatelně asociativní pole v jiném formátu"?

<!–texy–>[16] "Hovadinou" jsem nazval ty funkce, které místo erroru vracejí null (protože mi přijdou nesmyslné a očekával bych tuto vlastnost od php samotného).

Můžu se zeptat, jakým postupem kontrolujete ta asociativní pole přicházející do nějaké funkce? Hned na začátku, kdy zkontrolujete strukturu a případě špatné struktury vypisujete error? Pokud ano, jak probíhá kontrola těch částí pole, která nemusejí být vyplněna – jsou nepovinná? Nebo kontrolujete v běhu, kdy se před dotazem na ten který index vždy první ptáte na existenci ..? Co když neexistuje a je nepovinný?

<!–texy–>[15] Rozhodně souhlasím s Davidem. Já naopak tuto vlastnost PHP vítám a ani náhodou ji nepovažuji za nepříjemnost nebo dokonce "hovadinu". Podobně jako přístup k neinicializované proměnné, je i přístup a vůbec práce s neinicializovaným polem z principu nevhodná.

Bez těchto hlášek by se mnohem hůře odhalovaly nejen zmiňované překlepy, ale obecně případy, kdy přijde neočekávatelně asociativní pole v jiném formátu atp. Má praxe říká jednoznačně – E_NOTICE zapnout a poctivě se jin věnovat, jinak se to dříve či později vymstí (hlavně u větších aplikací, na kterých se podílí větší množství vývojářů).

<!–texy–>V napsání nějaké funkce není problém myslím. Jde mi o přístup. Vždyť je to hovadina, takové obezlice. Jenom proto, aby se poddalo pravidlu E_NOTICE.

… ta má kontrolovat překlepy apod. ale uvedenými způsoby se stejně dosahuje akorát toho, že následné překlepy zůstanou, akorát se nevypíšou jako chyba.