Na navigaci | Klávesové zkratky

Programátoři chyby neignorují

Tedy alespoň by neměli. PHP je jazyk s poměrně laxním přístupem k chybám a tudíž vyžaduje od programátora vyvinout větší úsilí při jejich ošetřování. Nenechte si namluvit opak. Článek je reakcí na dobře míněnou radu Jakuba Vrány.

Existují dva tradiční způsoby, jak chyby oznamovat:

  • vyhozením výjimky
  • návratovou hodnotou

Takřka všechny knihovny dodávané s PHP používají druhý způsob, protože výjimky byly do jazyka zavedeny až v páté verzi. Což je v mnoha případech na škodu. Programátor totiž musí neustále otrocky kontrolovat návratové hodnoty a ošetřovat chybové stavy. A zároveň je tu riziko, že na to zapomene. Přesněji řečeno, ani ne tak „zapomene“, jako spíš se na to „vy…kašle“, protože to ve světě PHP platí za normu. Nakonec, podívejte se třeba do dokumentace fread a spočítejte, kolikrát v příkladech ošetřili návratovou hodnotu jakékoliv funkce.

Při takovém stylu práce pak není divu, že programátoři považují výjimky za něco otravného, co se (cituju Jakuba) „nedá ignorovat“, zatímco „chyby indikované návratovou hodnotou ignorovat lze a program nejspíš nějak pracovat bude.“ Notykrávo.

Co přesně znamená ono nějak pracovat? Třeba:

// přesouváme z disku na disk
copy('c:/oldfile', 'd:/newfile');
unlink('c:/oldfile');
// pokud první operace selže, soubor se nenávratně smaže
$link = new mysqli('localhost', $user, $pass, 'eshop');
...
$link->query('USE testdata'); // přepneme se z ostré do testovací databáze
$link->query('DELETE FROM orders');
// pokud předchozí operace selže, vymažou se objednávky z ostré databáze
// BTW věřili byste, že výchozí nastavení query() při chybě nevyhodí ani noticku?
// smažeme soubor z adresáře 'test'
ftp_chdir($connection, 'test');
ftp_delete($connection, 'database.sdb');
// pokud předchozí operace selže, vymaže se kupříkladu ostrá databáze

A pak jsou případy, kdy nějak pracovat znamená zařvat s neošetřitelnou fatální chybou:

// načtení konfigurace
$defaults = array('host' => 'localhost', 'charset' => 'utf8');
$config = parse_ini_file('config.ini');
$config = $config + $defaults;
// pokud předchozí operace selže a vrátí false, skončí sčítání fatální chybou
function saveConfig(array $config) {   ...  }

$config = parse_ini_file('config.ini');
saveConfig($config);
// pokud předchozí operace selže a vrátí false, skončí opět fatální chybou
mysqli_connect('localhost', $user, $pass)
	->query("SET NAMES 'utf8'");
// pokud první operace selže, skončí opět fatální chybou

Bastlení zdar!

před 14 lety v rubrice PHP | blog píše David Grudl | nahoru

Mohlo by vás zajímat

Komentáře

  1. Jakub Vrána #1

    A pak jsou taky chyby, které nijak zvlášť ošetřovat potřeba není a které zbytek kódu naopak ovlivnit nesmí. V odkazovaném článku uvádím třeba zvýšení počtu přečtení článku, v diskusi potom rozbor příkazů na jedné konkrétní stránce.

    Výjimky jsou výborné v situaci, kdy chyba v jednom příkazu ovlivní chování dalších příkazů. Pokud je naopak potřeba chybu izolovat tak, že ostatní příkazy nesmí ovlivnit, tak to při používání výjimek vede k opakovanému psaní prázdných bloků try {} catch {}. A na to programátoři taky často kašlou, takže z lokálních chyb zbytečně vznikají globální.

  2. David Grudl #2

    avatar

    #1 Jakube Vráno, psaní prázdných bloků try {} catch {} je snad ještě horší, než ignorování chyb indikovaných návratovou hodnotou.

    Problém je, že ty v článku neuvádíš jako příklad chyby, kterou nijak zvlášť ošetřovat není potřeba, „zvýšení počtu přečtení článku“, ale „mysql_query“. Což je patrné nejen z článku, ale i následné diskuse.

    před 14 lety | reagoval [4] Jakub Vrána
  3. Pavel #3

    A nějakou chytrou knihovničku jak to v PHP dělat a neupsat se při tom k smrti (což považuji při absenci výjimek a velmi bizardních návratových hodnotách u většiny bultin funkcí za reálné nebezpečí) bys neměl? 🙂

    Jo a ještě jedna rejpavá: „Tedy by alespoň by neměli. “ ← jedno „by“ by mohlo stačit. 🙂

    před 14 lety | reagoval [6] David Grudl
  4. Jakub Vrána #4

    #2 Davide Grudle, Ale vůbec ne. Uvedl jsem pouze to, že zrovna u mysql_query by se někdy hodilo, aby vyhazovala výjimku (u chyb, které mají vliv na zbytek programu – tedy třeba načtení detailu článku) a jindy ne (třeba u oné inkrementace čítače, která by zbytek programu ovlivnit neměla). Z rozboru jedné konkrétní stránky vyplynulo, že lokálních chyb bývá převaha.

    Uveď prosím kód pro inkrementaci databázového čítače, který používá databázovou funkci vyhazující výjimku.

    před 14 lety | reagoval [5] Pavel [6] David Grudl
  5. Pavel #5

    #4 Jakube Vráno, A nebylo by lepší dávat sql dotazu jako další parametr něco ve smyslu „required“ (který by byl zároveň i výchozí) a při selhání by vyhodil výjimku, zatímco u inkrementování by se hodil False a prošlo by se třebas jen s Notice; popř. novou funkci (eg. dibi::easy() 🙂 ), která by dělala to samé co require=False 🙂?

    před 14 lety | reagoval [17] David Grudl
  6. David Grudl #6

    avatar

    #3 Pavle, některé knihovny lze k vyhazování výjimek přimět (například mysqli příkazem mysqli_report(MYSQLI_REPORT_ALL)), jindy se dá použít nadstavba, trošku experimentální je E_WARNING konvertovat na výjimky.

    #4 Jakube Vráno, z rozboru té konkrétní stránky vyplynulo, že obsahuje 9 DB příkazů a pouze v jednom případě nekontroluješ návratovou hodnotu.

    před 14 lety | reagoval [7] Jakub Vrána
  7. Jakub Vrána #7

    #6 Davide Grudle, Ale vůbec ne, to jsi pouze nepozorně četl. Návratovou hodnotu je naopak nutné kontrolovat pouze ve dvou případech, v sedmi případech je z pohledu uživatele vhodné, aby se s chybou pracovalo stejně jako v případě, že dotaz nevrátí nic (a z pohledu aplikace se chyba pouze zalogovala). Při použití výjimek by to znamenalo sedm prázdných try-catch nebo riziko eskalace lokální chyby na ostatní příkazy.

    Můžeš prosím uvést ten kód pro inkrementaci databázového čítače, který používá funkci vyhazující výjimku?

    před 14 lety | reagoval [9] David Grudl [12] mishak [25] David Grudl
  8. Tomáš Kavalek #8

    avatar

    Zajímavé počteníčko. Je však bohužel pravdou, alespoň z mého pohledu to tak je, že začínající programátory ukázky na PHP.net přímo k takovýmto krokům vedou.

    Například jak bylo uvedeno u příkladu s funkcí fread – začínající „programátoři“ v PHP pak mohou nabýt dojmu, že je to tak v pořádku a není třeba nic ošetřovat.

    před 14 lety
  9. David Grudl #9

    avatar

    #7 Jakube Vráno, v těch sedmi případech tedy nekontroluješ návratovou hodnotu funkce mysql_query a rovnou ji předáváš do mysql_fetch_assoc? V případě mysqli bys rovnou psal mysqli_query(...)->fetch_assoc()?

    Kód máš ve svém článku.

  10. Almad #10

    avatar

    Au.

    Ten původní článek.

    Au.

    Nemám tě rád, nevěděl bych o něm.

    před 14 lety
  11. Milan Prokeš #11

    avatar

    Jakub je prostě bastlíř a jeho jediný problém je v tom, že se tím veřejně chlubí, píše bastlířské knihy a ještě to bastlení vyučuje.

    V době jazyka C by si ani neškrtl. V době PHP je z něj internetová celebrita a vzor začínajících programátorů :(

    před 14 lety | reagoval [35] Dr.Diesel [36] Dr.Diesel
  12. mishak #12

    avatar

    #1 Jakube Vráno, „Pokud je naopak potřeba chybu izolovat tak, že ostatní příkazy nesmí ovlivnit“
    V takových případech je lepší napsat wrapper který API třetí strany schová, pokud jde o vlastní kód nezbývá než refaktorovat a bloky kódu nižší úrovně logiky zabalit do funkcí.

    #7 Jakube Vráno, Není pak přehlednější napsat dvě funkce, které budou splňovat požadované chování?

    před 14 lety
  13. Martin Hanák #13

    avatar

    #1 Jakube Vráno, Bohužel PHP je dosti benevolentní a když něco vyhazuje výjimku, tak ji programátor ošetřit nemusí, narozdíl třeba od Javy, která v tom případě neumožní překlad. Pokud tedy jde o vytváření globálních chyb z lokálních je to opět záležitost PHP, v Javě se musí metoda označit explicitně klíčovým slovem throws, aby výjimka probublala výš (a to i v případě ručního volání throw).

    I když bych tedy měl psát několik „prázdných“ bloků try-catch, tak mi to přijde programátorsky čistší. Skoro to vypadá, že ti jde o vlastní pohodlí, než o bezpečnost kódu 🙂

    před 14 lety | reagoval [14] v6ak
  14. v6ak #14

    Mnohé tu již bylo řečeno.
    #13 Martin Hanák Ještě dodám, že toto se týká často z nepochopitelného důvodu kritizovaných řízených výjimek (např IOException). Neřízených výjimek (IllegalArgumentException, NullPointerException, …) se to netýká, protože u správného kódu obvykle nenastávají a ošetřovat je by bylo peklo.

    Tyto dva články a dnešní noční update mě inspirovaly k jednomu dotazu: co takhle nějaké bezpečné polykání výjimek (s logováním) u továrniček v Nette? Anotace NonCritical, nějaká sorry šablona?

    před 14 lety | reagoval [16] Jakub Vrána
  15. Jakub Vrána #15

    Panuje obecné přesvědčení, že výjimky jsou ten nejlepší způsob zpracování chyb. Můj článek pojednává o tom, že v některých případech výjimky příliš výhodné nejsou a šikovnější je reportování chyb pomocí návratové hodnoty. Konkrétně jde o případy, kdy chyba v jednom příkazu nesmí ovlivnit ostatní příkazy.

    Každou potenciální chybu je samozřejmě potřeba náležitě ošetřit a ať čtu článek a navazující diskuse jak chci, nikde nevidím, že bych tvrdil opak. Jde jen o to, že u izolovaného příkazu je ošetření chyby při použití návratové hodnoty (a zalogovaného varování PHP) zadarmo.

    Řekněme, že chceme SQL příkazem zvýšit čtenost článku a pokud u toho dojde k chybě, tak tím nechceme otravovat uživatele, ale pouze programátora (pomocí chybového logu):

    <?php
    // v pořádku - pokud dojde k chybě, tak se zaloguje
    mysqli_report(MYSQLI_REPORT_ERROR); // zapnutí varování pro SQL příkazy (na ostrém se logují)
    mysqli_query($mysqli, "UPDATE ... ctenost = ctenost + 1 ...");
    
    // teď je to bastlení - může dojít k nezachycené výjimce
    mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); // zapnutí výjimek pro SQL příkazy
    mysqli_query($mysqli, "UPDATE ... ctenost = ctenost + 1 ...");
    
    // v pořádku, pouze je kód poněkud krkolomnější
    mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
    try {
    	mysqli_query($mysqli, "UPDATE ... ctenost = ctenost + 1 ...");
    } catch (mysqli_sql_exception $e) {
    	// bez tohoto řádku by šlo taky o bastlení
    	error_log($e);
    }
    ?>

    Při použití výjimek se tedy dá bastlit úplně stejně jako při použití návratové hodnoty. Dost už tedy prosím těch keců o bastlení, pokud se chyby ošetřují pomocí návratové hodnoty.

    před 14 lety | reagoval [17] David Grudl
  16. Jakub Vrána #16

    #9 Davide Grudle, Já jsem po tobě chtěl ten kód proto, že protestuješ proti prázdným blokům try-catch.

    #14 v6aku, O jakém nočním update mluvíš?

    před 14 lety | reagoval [17] David Grudl [21] v6ak
  17. David Grudl #17

    avatar

    #15 Jakube Vráno, aha… všimni si, že s prvním odstavcem nikdo nepolemizuje, namátkou #5 Pavel navrhuje udělat „tichou“ variantu jinak výjimkové mysql_query + řada podobných komentářů u tebe v diskusi. Je dáno kontraktem metody, jak bude chybu hlásit a návratové hodnotě se nikdo nebrání.

    Co nazývám bastlením je poslední odstaveček se zmínkou, že chyby indikované návratovou hodnotou lze ignorovat a program bude nejspíš nějak pracovat. Tedy v kontextu článku, že s výjimkami je vše mnohem složitější. Nezachycená výjimka je menší zlo, než skončit s nekonzistentními daty a ještě vypadat, že je vše ok.

    #16 Jakube Vráno, ovšem ani tam prázdný catch není – je tam logování. Nicméně protestoval jsem proti systematickému psaní prázdných catch via #1 Jakub Vrána.

    před 14 lety | reagoval [18] Jakub Vrána [19] Jakub Vrána
  18. Jakub Vrána #18

    #17 Davide Grudle, Opravdu bych nečekal, že se celá kauza nakonec vysvětlí tím, že nepochopíš psaný text. Poslední odstavec mého článku je holé konstatování faktu. Není to nějaký návod nebo doporučení, že něco lze, je to jen popis skutečného chování. A vysvětlil to už Bronislav Klučka v první reakci na Martina Hrušku, který to jako první nepochopil.

    Já jsem dokonce napsal reakci, kde jsem Martinu Hruškovi doporučil přestěhování do Severní Koreje, pokud chce lidi střílet za prosté konstatování faktu. Nicméně po vysvětlení Bronislava Klučky mi přišla zbytečná, a tak jsem ji nepublikoval.

    před 14 lety | reagoval [22] David Grudl
  19. Jakub Vrána #19

    #17 Davide Grudle, Je třeba v Dibi nějaká obdoba metody query, která nevyhodí výjimku? Nevidím ji. Můžu si do modelu napsat metodu, která vrací třeba výběr článků a v případě výjimky vrátí false? To je nevhodné, protože na stránce určené výhradně pro výpis výběru článků je výjimka žádoucí. Naopak je nežádoucí na stránce, kde chci zobrazit komponentu s výběrem článků. Takže buď si můžu do modelu napsat metody dvě, nebo v prezenteru použít „návrhový vzor“:

    <?php
    try {
    	// tady bude jeden příkaz
    } catch (Exception $e) {
    	error_log($e);
    }
    ?>

    A tento „návrhový vzor“ použít u všech komponent, které pro zobrazení stránky nejsou kritické.

    A opravdu bych chtěl vidět kód nějaké větší aplikace, kde se z chyb v SQL příkazech vytváří výjimky, jestli tento „návrhový vzor“ poctivě používá u všech nekritických komponent. Vsadil bych si totiž na to, že řada z nich na to bude kašlat, takže bude zbastlená právě proto, že používá výjimky místo návratové hodnoty.

    před 14 lety | reagoval [22] David Grudl
  20. Proki #20

    avatar

    Už jsem to psal jinde, ale proč by měl jeden výběr selhat a jiný ne? Standardně v 99% proběhnou správně oba výběry a nebo ani jeden z nich (např z důvodu poruchy databáze)

    K tomu příkladu výše: pokud je to tedy nutné, co si do metody modelu přidat další nepovinný parametr, kterým by se určilo zda-li výjimku vyhodit nebo ne? Myslím si ale, že pokud je nutné často používat výše uvedený „návrhový vzor“, tak je chyba někde v návrhu aplikace a ne v tom, že bez výjimek by to bylo jednodušší.

    Programuji nebo programoval jsem i v JSP a ASP.NET, tam se to výjimkami jen hemží. Např i každé konvertování řetězce na číslo je potřeba ošetřit. O desktopových aplikacích vůbec nemluvím, tam stačí maličkost a už máme fatal. Jen PHP se vždy musí chovat jinak.

    Jednoznačně jsem tedy pro výjimky a souhlasím s Davidem.

    před 14 lety | reagoval [35] Dr.Diesel [36] Dr.Diesel
  21. v6ak #21

    Ukázali jsme si, že existuje alespoň jeden případ, kdy jsou výjimky příjemnější a alespoň jeden případ, kdy je příjemnější návratová hodnota. Na webu se možná vyskytuje druhá možnost častěji než jinde, ale ne tak často, jak by se mohlo na první pohled zdát, protože při dvou a více na sobě závislých operacích (např. query a fetch) se to bez nich již začíná komplikovat. U menších částí to bude ještě únosné, u větších to bude peklo.
    Z vlastní zkušenosti bych neváhal, pokud bych z těchto dvou způsobů měl vybrat jeden univerzální a vybral bych výjimky.

    Jinak konec souboru není zvykem řešit výjimkou, i v Javě je to návratovou hodnotou: https://web.archive.org/…tStream.html

    Pravda, i v Javě se občas vyskytují věci, nad kterými zůstává rozum stát, např. https://web.archive.org/…io/File.html , ale na řešení metody read jsem ještě stížnost neviděl.

    #16 Jakube Vráno, Na jednom webu jsme dělali update a já byl po ruce pro případ, že by byl problém. Dostali jsme se k nějakému problému s DB, která ale postihla i ErrorPresenter. Krásný příklad toho, že se hodí udělat nekritické části webu. A lazy připojení. Zároveň jsem se dostal k myšlence, že ona neelegantnost výjimek by šla vyřešit, kdyby se jednotlivé bloky nekritického potenciálně problematického kódu uzavřely do speciálních metod volaných nějakým systémem, který by v případě nekritických metod jen napsal chybovou hlášku a zalogoval výjimku.
    U komponenty může taková chyba nastat hlavně u render a v továrničce. Bylo-li by nekritickým komponentám přiřazeno takovéto chování, snížilo by to význam reportování chyb návratovou hodnotou hodně blízko k nule.

    před 14 lety
  22. David Grudl #22

    avatar

    #18 Jakube Vráno, že nepochopím psaný text se může docela dobře stát, o tom žádná. Aby ses nezlobil, mám pro tebe námět na dobře míněnou radu: „V PHP nemusíte kód odsazovat a můžete ho dokonce vtěsnat na jeden řádek.“ Holý fakt, za ten se nestřílí a Pythonisti můžou závidět 😉

    #19 Jakube Vráno, V Dibi obdoba metody query, která nevyhodí výjimku není. Proč? Odpovím ti (odpovíš si) hned, jak odpovíš na #9 David Grudl. Stále jsem v očekávání.

    Mimochodem, bastlíř je v původním slova smyslu totéž, jako byl v původním slova smyslu hacker. Když už to ale používáme jako negativní přívlastek – myslíš si, že aplikace ukončená nezachycenou zalogovanou výjimkou představuje větší zlo, než aplikace tiše páchající nekonzistenci dat? (otázka je obecná a netýká se zobrazení stránky tvého blogu).

    před 14 lety | reagoval [24] Jakub Vrána [27] Jakub Vrána
  23. Jakub Vrána #23

    #9 Davide Grudle, To už jsem dávno napsal ve své diskusi.

    před 14 lety | reagoval [25] David Grudl
  24. Jakub Vrána #24

    #22 Davide Grudle, Menší zlo je samozřejmě aplikace ukončená nezachycenou výjimkou. Stejně tak se ale dá položit otázka, jestli je lepší aplikace ukončená nezachycenou výjimkou kvůli chybě v nepovinné komponentě nebo aplikace, která tuto chybu zaloguje a komponentu pouze nezobrazí.

    Já nikde netvrdím, že výjimky jsou pro ošetření chyb nevhodné. V některých situacích jsou samozřejmě velmi užitečné. Jindy jsou ale spíš na obtíž a vedou k psaní neelegantního kódu.

    před 14 lety
  25. David Grudl #25

    avatar

    #23 Jakube Vráno, ten kód jsem chtěl vidět jako protiargument k #7 Jakub Vrána že návratovou hodnotu je nutno kontrolovat takřka ve všech případech. Což je samozřejmě správně, ukazuje to na povahu mysql_query jako nízkoúrovňové funkce a pokud by vyhazovala výjimku, jediný rozdíl v kódu by byl v záměně if (!$result) na catch (DbException $e). Výhoda výjimky je v tom, že zapomeneš-li, nenastane větší zlo (a co je větší zlo jsme se shodli). A z pohledu elegance mám rád mysqli_query(...)->fetch_all().

    Tvému přeformulování otázky se nijak nebráním. A s posledním odstavcem zcela souhlasím. Kdyby zazněl ve tvém článku, nevznikne tento.

    před 14 lety
  26. Tonda #26

    avatar

    Tu vášnivou diskuzi jsem nečetl, nicméně myslim, že z těch ukázek v článku je krásně vidět, že PHP se nedá s klidem použít na něco seriózního.

    před 14 lety | reagoval [31] vedouci
  27. Jakub Vrána #27

    #22 Davide Grudle, Vezměme to z druhého konce. Když čtenář nepochopí myšlenku pisatele, tak je to často chyba pisatele, obzvlášť když je takových čtenářů víc. Beru to tedy tak, že jsem napsal článek, který mohl být špatně pochopen. Doplnil jsem do něj nyní drobný dovětek s odkazem na tento článek, který celkové vyznění snad trochu vyváží.

    před 14 lety
  28. Jakub Vrána #28

    Proč se mi ukázky zdají nevhodně vybrané a jak je to s těmi příklady u funkce fread: Jak je to s těmi chybami?

    před 14 lety
  29. Honza #29

    před 14 lety
  30. vedouci #30

    avatar

    nechtělo se mi číst ten flame tady, všichni to jistě víte, ale ne každý si to při psaní reakce uvědomil:

    vyjímka (narozdíl od chyby) přeruší control-flow – skočí někam úplně jinam (do try-catch a nebo do exception handleru) a pokud jazyk nepodporuje rescue (jako např. ruby), tak nejsou vždy nejlepším řešením – protože už se prostě nikdy nedostanu zpátky. (pokud nepíšu na každém řádku try-catch – všem obhájcům vřele doporučuju zkusit programovat v javě, tam si vyjímek tak užijete, že se ještě rádi vrátíte.

    před 14 lety | reagoval [32] v6ak
  31. vedouci #31

    avatar

    #26 Tondo, no jasně, zlato, tak si běž plakat někam jinam…

    před 14 lety
  32. v6ak #32

    #30 vedouci, V Javě jsem si výjimek užil a dal bych si ještě 🙂 Ačkoli se najdou věci, které bych v Javě změnil (a většinou jsou změněné v JavaFX Scriptu), ale u výjimek bych toho moc neměnil.

    před 14 lety | reagoval [33] vedouci
  33. vedouci #33

    avatar

    #32 v6aku, dej vedet za rok, za dva ;)

    před 14 lety | reagoval [34] v6ak
  34. v6ak #34

    #33 vedouci, Od seznámení s Javou už přes dva a půl roku uplynulo…

    před 14 lety
  35. Dr.Diesel #35

    #20 Proki, Kde to mam podepsat?

    Ad dgx vs. Jakub : Co blbnete, roztrhejte si obcanske prukazy 😁 Presne jak je psano v #20, v 99% pripadu na webu to bud projde cely nebo nic. O zbytek nema imho smysl se hadat a provozovateli casto jde predevsim o tu drtivou vetsinu se snadnou moznosti upravy kodu, nez o slozity/neprehledny, byt radoby100% kod.

    #11 Milane Prokeši, Vykrik do tmy bez reakce. Nechapu duvod, proc sem vsichni motaji C nebo Javu. Kdybych chtel tridu zacit psat s tunama getteru / setteru, pustim se do toho. Jsem linej a pisu v PHP. Imho je cesta nekde uprostred, tj. nejspis co popisuje Jakub: corebusiness vyhazovat na vyjimky, „kraviny“ napsat jednoduse. PHP mi umoznuje si vybrat, java, C, C# me tlaci do striktnosti – jo, sem linej a … to uz sem rikal 😁

    před 14 lety
  36. Dr.Diesel #36

    #20 Proki, Kde to mam podepsat?

    Ad dgx vs. Jakub : Co blbnete, roztrhejte si občanské průkazy 😁 Přesně jak je psáno v #20, v 99% případů na webu to buď projde celý nebo nic. O zbytek nemá imho smysl se hádat a provozovateli často jde především o tu drtivou vetšinu se snadnou možností úpravy kódu, než o složitý/nepřehledný, byť rádoby100% kód (o ten jemu často navíc nejde vůbec).

    #11 Milane Prokeši, Výkřik do tmy bez reakce. Nechápu důvod, proč sem dotyční motají C nebo Javu. Kdybych chtěl třídu začít psát s tunama getterů / setterů, pustím se do toho. „Jsem línej a píšu v PHP, zastřelte mě“ :) .

    Imho je cesta někde uprostřed, tj. nejspíš co popisuje Jakub: v corebusiness vyhazovat na výjimky, „kraviny“ napsat jednoduše. PHP mi umožňuje si vybrat, Java, C, C# me tlačí do striktnosti – jo, sem línej a … to už sem říkal 😁

    před 14 lety
  37. LamiCZ #37

    Kdyby byly všechny jazyky stejný, tak by logicky stačil jeden a my bychom to měli jednoduchý. K čemu mít 10 stejných jazyků, které by se lišily jen syntaxí? IMHO nesmysl. Každý se hodí na něco jiného a zdá se, že ve své oblasti se uchytily, jelikož přežily dost dlouho…

    před 14 lety

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.


phpFashion © 2004, 2024 David Grudl | o blogu

Ukázky zdrojových kódů smíte používat s uvedením autora a URL tohoto webu bez dalších omezení.