Při testování metodou bílé skřínky (white box) je obecná snaha o co největší pokrytí testovaného kódu (code coverage). Minimálně byste se měli snažit o to, abyste testy pokryli každý řádek vašeho programu, který stojí za to testovat (např. obě větve každého úplného if-else příkazu, ale už ne třeba situace typu assert false, 'x > 0; this should never happen'). O tom, jak si zjistit aktuální pokrytí vašeho kódu v jazyce Python bude následující příspěvek.

V tomto příspěvku naznačím důvod, proč nemůže pro jazyk C existovat LL(k) gramatika pro libovolné konečné k. Příspěvek si asi užijí jen ti, kteří mají určité základy z oblasti teorie formálních jazyků a překladačů, ale do žádných složitých detailů se pouštět nebudu.

Konec října a začátek listopadu je sice obdobím polosemestrálních zkoušek, ale i přesto zkusím hodit do placu další hádanku. Za poslední tři hádanky byl průměr odpovědí čístá nula, takže i když se ani teď nikdo neozve, tak průměr neklesne. Je třeba myslet pozitivně :). Dneska se bude řešit korektní načítání čísel ze vstupu pomocí C++ proudů (streams).

Někteří o mně určitě ví, že mým oblíbeným způsobem vývoje softwaru je vývoj řízený testy (test-driven development, někdy také nazýváno test-first development - dále jen TDD). Jedním z důvodů, proč na tento přístup nedám dopustit, je to, že jeho aplikováním vzniká něco, co většina softwaru postrádá - čistý kód, který funguje.

Přínáším první hádanku v novém školním roce. Styl této hádanky bude podobný stylu předchozí hádanky, kdy se hledala potenciální chyba v programu, ovšem s tím rozdílem, že tato hádanka nebude ani tak o hledání "jazykových chyb", jako spíše o hledání návrhových chyb.

Při čtení "Dračí knihy" (Dragon book) jsem narazil u jednoho příkladu ruční implementace konečného automatu na poznámku, že nezáleží na pořadí uvedených case větví v příkazu switch, protože překladač to optimalizuje, a tudíž, i když tu nejméně pravděpodobnou variantu dáme na začátek, tak to nebude mít na výkon žádný vliv. Co se týče nezávislosti na pořadí (mimo speciální případy, např. vynechaný break), tak v jazycích C a C++ je to běžně známá záležitost, ale mě zaujala ona poznámka o optimalizaci a nedalo mi to, abych se nepřesvědčil, jak tomu ve skutečnosti je. Se svými výsledky, co se týče překladače gcc, bych se chtěl podělit v tomto příspěvku.

Před koncem letního semestru jsem se rozhodl, že přes následující letní prázdniny shodím část přebytečných tuků, které se mně podařilo za poslední čtyři roky, co jsem na VŠ, přibrat (přesněji řečeno se jednalo především o první tři roky - ten čtvrtý už jsem začal něco dělat). Dnešní příspěvek je o mé cestě a výsledkem po téměř 4 měsících práce.

Dneska bych se chtěl mrknout na implicitní číselné typy v jazyce Haskell (podle specifikace z roku 1998, příklady odzkoušeny v GHC 6.10). Jak určitě víte, tak při použití funkcí jako je read :: Read a => String -> a je nutné specifikovat, co má být výsledným typem. Pokud zavoláte jenom read "143", tak překladač nedokáže automaticky odvodit konkrétní typ takového výrazu (netuší, že chcete z řetězce získat číslo typu Int). Řešením je typ výrazu explicitně zadat, čili read "143" :: Int. Tato nejednoznačnost se ale netýká jen takovýchto výrazů, ale i zdánlivě "jasných" výrazů.

Jelikož programuji a zajímám se i o jiné jazyky než je C a C++ (Python, Haskell, Java, SQL, PHP, HTML/XML, CSS, JavaScript, LaTeX, Vimscript, minoritně o Prolog či různé assemblery, dříve Pascal), tak jsem se rozhodl, že občas napíšu i nějakou zajímavost z ostatních jazyků. Nebude to nijak závazné, ani neplánuji žádný pravidelný seriál, ale když při studiu/programování narazím na nějakou zajímavost, tak ji sem možná napíšu :). Témata na tom budou (co se týče obtížnosti) různá - především se ale asi bude jednat o pokročilá témata.

Ne, vhodnější nadpis, než je zbytečná tautologie v druhé části, mě opravdu nenapadl :). Debian Testing jsem na svém notebooku používal od srpna minulého roku až do poloviny února, kdy byl uvolněn Debian Lenny a já jsem (z důvodů dočasné absence bezpečnostních updatů) zůstal na stabilní verzi (Lennym). Po ukončení semestru jsem však na začátku června opět přešel na testovací verzi Debianu, na které jsem zůstal až do začátku srpna tohoto roku, kdy jsem přešel na "nestabilní" verzi Debianu - Unstable. Mé důvody a dojmy po měsíci používání naleznete dál v příspěvku ;).