Hledání chyb v kódu

Krásný večer všem, kteří ještě neshledali spánek řešením dnešní noci.
Nebudu to zbytečně moc okecávat a půjdu rovnou k věci.
Na svém čerstvě spuštěném blogu jsem sepsal článek (místy je to spíš povídka) o hledání chyb v kódu.
Jsem si vědom toho, že podobný článek je přímo v učebnici, ale ten se zaměřuje spíše na debuggování na základě chybových hlášek.
Rád bych věděl, zda by byl o něco podobného zájem (třeba nějaký výcuc ořízlý o to vyprávění na pozadí) do učebnice, do zdejšího FAQ nebo mám radši dělat, že jsem nikdy nic nenapsal :).
Článek jsem akorát dopsal a 2x přečetl. Jsem si plně vědom toho, že v tuto noční hodinu tam bude při takovém množství textu velká spousta pravopisných, gramatických a určitě i stylistických chyb. Mile rád opravím cokoliv, čeho si zdejší oči všimnou.
Budu rád i za připomínky k obsahu samotnému. Samozřejmě za předpokladu, že by nápad zaujmul a dalo by se hovořit o tom, že by bylo reálné pro něj najít nějaké využití.
Předem děkuji za reakce (i když je očekávám až spíš zítra/dnes dopoledne) a přeji hezký zbytek noci ;).
Edit: A samozřejmě odkaz :)

Toho jsem se bal. Jedna se o moje zjednodušení původního kódu. Myslíš ze by bylo lepší pracovat s původním kódem na úkor nepřehlednosti?

tiso:
Mluvíme oba o $povolene_formaty = array("jpg", "jpeg");?
Pokud ano, tak k tomu se vztahovala má otázka. Pro hledání chyby v kódu je tato má úprava nedůležitá a je to jen pro přehlednost. Jednoduše jsem místo složené podmínky použil in_array(). Můj dotaz tedy stále platí. Navzdory tomu, že to funkčne s chybou nemá nic společného, myslíš, že když uvedu, že se jedná o ekvivalentní úpravu bude to pro cílové čtenáře matoucí?
Nebo myslíš, že bych měl nechat původní kód i na úkor přehlednosti?
Další variantou je ponechat mou úpravu a jen ji detailněji vysvětlit nebo napsat, že se nejedná o žádnou zásadní změnu.
To je to, proč píšu, abych dostal názory ostatních :)

Joker:
Můj původní nápad byl, že bych vždy, když bych narazil při své práci na situaci, kdy je třeba trocha toho "detektivování", napsal článek o tom, jakým způsobem jsem kód debugoval a jaké metody jsem využil. Při psaní článku jsem se marně snažil najít nějaké vlákno zde na diskusi, které by obsahovalo učebnicový příklad toho, co popisuji. Nakonec jsem zvolil Asyllyn problém, který mě prapůvodně inspiroval k tomu něco vůbec začít psát.
Pokud u sebe nebo zde na diskusi narazím na nějaký problém, který by stál za zvěčnění v článku, mile rád o něm napíši.
Nějaké poznámky k obsahu nebo se vše zdá být srozumitelné?
Co říkáš na:

[#5] Dan Charousek
„Nebo myslíš, že bych měl nechat původní kód i na úkor přehlednosti?“

tiso:
Co tedy navrhuješ?
Pracovat čistě s původním kódem?
Pracovat s mírně upraveným původním kódem (odřádkování, odsazování, struktura kódu).
Nebo klidně pracovat s upravenou verzí s tím, že by se měly detailněji popsat všechny, byť chybu neovlivňující změny?

tiso:
To je samozřejmost. Narazím-li při progrmaování na chybu je jisné, že ji přiřadím prioritu číslo jedna a vyřeším dřív než začnu přidělávat úpravy.
Ale jedná se o potřeby článku. Stále je ve vzduchu má otázka z [#9]. V dalších článcích budu pravděpodobně pracovat se svými kódy, ve kterých objevím chybu a budu je analyzovat, ale co v případě, že by se opět objevil nějaký kód z nějakého vlákna z diskuse?
Nemyslím si, že je vhodné pracovat s něcím takovým.
Já osobně jsem pro variantu, kdy se rozhoduje mezi upravením formátováním kódu (odsazování, odřádkování...) a většími zásahy do kódu s následným věsvětlením.
Dá-li sem někdo kód, kde bude podmínka
myslíš, že je od věci to upravit
a následně vysvětltit, že je to totéž a že to s chybou nemá nic společného?

Joker:
Rád z toho udělám něco jako seriál.
"Něco jako", protože by díly vycházeli nepravidelně na základě toho, jestli by bylo co zpracovávat.
Souhlasím s tím, že do učebnice jako takové se to nehodí a otázkou je, zda by počet článků neodradil od čtení.
Jedna z možností je odkazovat na úvodní článek, s tím, že snad z něj bude dostatečně jasné, jak postupovat ve všech možných případech nebo se snažit typově přiblížit konkrétnímu problému (někdo bude mít problém s mysqli při práci s db a bude existovat díl, kde se řeší chybný výpis z db), tak na něj odkážu.
Druhá možnost je pokusit se sepsat nějaké obecné rady, na které by se odkazovalo nebo se přímo zapasovaly do učebnice, ale nejsem si úplně jistý, jestli se dá něco takového obecně popsat. Teoreticky to jde jednou větou. Je tam opravdu to, co čekáte, že by tam mělo být? Ale všichni víme jak to je.
Jako další mě napadá vytvořit učebnicový kód, který by obsahoval časét situace a vytvořit tam ty chyby úmyslně. Mně se to nelíbí a myslím si, že by to bylo zbytečně dlouhé a jednalo by se o takový pokus shrnout všechny potencionální díly seriálu do jednoho článku.
Další možnosti mě momentálně nenapadají, budu rád za jakéliv návrhy.

DJ Miky:
Tomu nerozumím. Změnil jsem při úpravě scriptu něco jiného než jen to, že script vyhodnocuje koncovku na základě pole s povolenými formáty a tím, že nyní podporuje i .jpeg?

DJ Miky:
Ah, máš pravdu, nějak jsem se zasekl v přirozených číslech (a nule). Opravil jsem to, tak snad jsem tam zas nenasekal chyby :)
Snad to popisuje, co jsem měl na mysli.
Situace je podle mě taková, že článek by se začal psát stejně až po vyřešení chyby, tudíž já vím, co můžu změnit bez toho, aniž bych chybu ovlivnil.
Stačí pak napsat, že jsem upravil to a to, ale na chybu to nemá sebemenší vliv?
Nebo radši opravdu pracovat s původním kódem a maximálně ho trochu lépe naformátovat?

tiso:
Ve chvíli, kdy najdu chybu už nepotřebuju kód upravovat, jde mi spíš o přehlednost v průběhu hledání té chyby.
Jinak děkuji za názor.

Z přirozených čísel jsem se sice posunul do celých, ale zapomněl jsem na ta reálná :)
Nechtěl jsem tam tahat in_array, ale ve finále jsem si to jen zkomplikoval, díky za připomínku a doufám, že od teď se nebudeme muset zabývat mou nepozornosti :)