Každý člověk dělá chyby. Při programování to platí více než v jiných technických oborech. Proč ale propadat zoufalství, když to můžeme otočit v náš vlastní prospěch? Chytří využijí chyby k tomu, aby se naučili je příště nedělat.
Programátoři jsou chytří. Proto si vytvořili nástroje a postupy, které jim umožňují chyby hledat a chápat. Pro systematické hledání chyb slouží testování. Pro podporu hledání a pochopení chyb slouží ladícího programy – debuggery. Ani testování ani ladění vám sice nezaručí, že najdete všechny chyby, ale je to mnohem lepší než programování metodou pokus–omyl.
Překvapivě mnoho studentů programování má pocit, že debugger nepotřebují. Proč s ním ztrácet čas? Proč se učit ovládat další nástroj? Protože vám ukáže, jak program opravdu funguje a pomůže vám přemýšlet o problémech správným způsobem. V důsledku vám bude tvorba projektu trvat mnohem kratší dobu než bez něj.
Používejte debugger a další ladící nástroje, kde to jen jde. I když to na první pohled nevypadá, šetří to práci a zmenšuje to frustraci, když vám něco nefunguje. Používají jej i borci, kterým se zdají sny ve strojovém kódu, tak proč ne vy? I tihle borci vědí jakou cenu mají znalosti získané z vlastních chyb.
Pokud se zrovna učíte programovat, naučte se používat debugger dříve, než zvládnete všechna ostatní zákoutí programování. Učit se programovat je mnohem zábavnější s debuggerem než s učebnicí, protože to umožňuje zkoumat a objevovat nové věci vlastní cestou.
V anglickém technickém slangu se chybě říká bug, což se dá přeložit jako brouk. Etymologie tohoto termínu je jistě zajímavá a nakonec i v češtině říkáme, že "to má mouchy", když něco nefunguje. V programátorské praxi existuje několik druhů chyb a je potřeba si uvědomit, za co může programátor a za co ne.
Programátor většinou nemá žádný vliv na chyby vznikající mimo jeho program. Obvykle jsou to hardwarové chyby, existují ale i softwarové chyby, na které programátor nemá vliv.
Příkladem je nedostatek volné paměti, nebo chyba v programu, se kterým ten náš spolupracuje. Extrémním případem pak mohou být chyby v samotném operačním systému. Za tyto chyby programátor nenese přímou zodpovědnost. To ale neznamená, že je může ignorovat.
Často s těmito chybami může pomoci operační systém nebo ovladač tím, že umožní detekovat chybové kódy pro různé chybové stavy (v OO jazycích to lze řešit výjimkami). Programátor musí tyto kódy testovat a ošetřovat. Čím větší škodu může chyba způsobit (program pro řízení jaderné elektrárny, projekt do školy), tím větší pozornost si zaslouží.
Syntaktické chyby jsou prohřešky proti gramatice programovacího jazyka. Při překladu je odhalí překladač. Menší syntaktické chyby odhalí i některé chytřejší editory. Je tudíž dobré zdrojový soubor pro kontrolu přeložit vždy po napsání nějakého kousku kódu (cyklus, tělo funkce).
Pokud je projekt dlouhý, trval by překlad dlouho, proto je výhodné dělit programy na moduly a hlavně používat make. Některé editory (např. vim) umí program make spouštět, aniž byste je museli opustit. Vývojová prostředí typicky umožňují spustit překlad příkazem z menu nebo klávesovou zkratkou.
Sémantické chyby jsou prohřešky proti sémantice, tedy proti požadovanému chování programu (sémantika = význam). Z principu je nelze detekovat automaticky (stroji musíme nejprve nějak sdělit, co po něm chceme). Způsobují chybnou funkci programu a právě na jejich odhalení se zaměřují všechny techniky hledání chyb, kterými se zde budeme dále zabývat.
Sémantické chyby v programech lze odhalit laděním, testováním a verifikací. Nikdy nejde o plně automatické techniky, ale o pomůcky, které usnadní ruční hledání chyb.
Nejlepším způsobem, jak se chyb zbavit, je vůbec je nedělat. K tomu jsou ovšem potřeba zkušeností. Zkušenosti se hodí i při samotném hledání chyb. Dále se zde uplatní intuice, abstraktní myšlení, představivost, ale i štěstí.
Laděním se obvykle myslí systematické hledání chyb pomocí krokování v debuggeru. To je program, který umožní zastavit běh programu po každém vykonání jednoho řádku programu nebo na předem definované zarážce (breakpoint). Pokud je laděný program pozastaven, lze si prohlížet či měnit obsah paměti či konkrétních proměnných, stav zásobníku, registrů a podobně. Tímto způsobem kontrolujeme, zda program skutečně dělá to, co jsme zamýšleli.
Testování je opět činnost jejímž primárním cílem je odhalit chyby. V tomto případě ovšem nesledujeme běh programu krok za krokem, ale snažíme se program spouštět za nejrůznějších (původně třeba nepředpokládaných) podmínek a sledujeme, jak se s nimi vypořádá. Testovat lze ručně nebo také pomocí různých skriptů a sofistikovaných testovacích nástrojů. V současné době existuje celé průmyslové odvětví, které se zabývá testováním aplikací.
Aby byl program testovatelný, musí být dobře navržen. Nešikovné uživatelské rozhraní může systematické testování úplně znemožnit. Pro testování jsou nejméně vhodná příliš upovídaná rozhraní s množstvím dialogových menu.
Jakkoli náročným testováním nelze zaručit, že testovaná aplikace je zcela bez chyb. (Ne)existenci některých tříd chyb lze matematicky dokázat pomocí speciálních programů.
Tímto se zabývá obor formální verifikace. V této oblasti v současné době probíhá intenzivní výzkum. Velké firmy počínaje Microsoftem a konče Boeingem, či NASA za výzkum v této oblasti utrácí ročně obrovské sumy peněz.
Zjednodušeně řečeno je princip formální verifikace takový, že matematicky popíšeme vlastnosti, které chceme v softwaru ověřit (například živost, dosažitelnost stavů, apod.) a pomocí verifikačního softwaru se snažíme dokázat, zda daná vlastnost platí či ne. Bližší vysvětlení však přesahuje rozsah toho, co zde chci říct (klíčová slova: formal verification, model checking).