IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG

TWJ KOSZYK
DODAJ DO KOSZYKA

CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK

CZYTELNIA
FRAGMENTY KSIEK ONLINE

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

Niezawodno
oprogramowania
Autor: Steve Maguire
Tumaczenie: Andrzej Grayski
ISBN: 83-7197-429-9
Tytu oryginau: Writing solid code: Microsoft's
techniques for developing bug-free C programs
Format: B5, stron: okoo 400
To wanie programista moe w znacznym stopniu przyczyni si do tego,
i wykrywanie bdw i walka z nimi stan si zadaniami atwiejszymi i bardziej
skutecznymi -- t wanie tez Autor stara si udowodni w niniejszej ksice,
ilustrujc swe wywody konkretnymi przykadami.
Niektre ze wskazwek i zalece zawartych w treci niniejszej ksiki sprzeciwiaj si
wielu powszechnie przyjtym praktykom programowania i jako takie prowokowa
mog do stwierdze w rodzaju nikt tak nie pisze lub wszyscy ami t regu.
Warto wwczas zastanowi si nad przyczyn -- jeeli nikt tak nie pisze, to dlaczego?
Czy przypadkiem stare nawyki nie okazuj si silniejsze od racjonalnoci?
Odpowied na te i inne pytania Czytelnik znajdzie w tej ksice.

SPIS TRECI

Przedmowa do wydania polskiego...................................................................9

Wstp ...............................................................................................................15
Dwa najwaniejsze pytania............................................................................................................16
Nazewnictwo .................................................................................................................................17

Rozdzia 1. Hipotetyczny kompilator ...........................................................21

Poznaj swj jzyk programowania ................................................................................................23
Poyteczne Narzdzie Lint .......................................................................................................27
To tylko kosmetyczne zmiany .......................................................................................................27
Nigdy wicej bdw .....................................................................................................................28

Rozdzia 2. Sprawdzaj samego siebie ...........................................................31

Przypowie o dwch wersjach .....................................................................................................32
Asercje ...........................................................................................................................................33
Niezdefiniowane oznacza nieprzewidywalne.........................................................................36
Zagadkowe asercje.........................................................................................................................37
Kompatybilno kontrolowana ......................................................................................................39
Gdy niemoliwe staje si moliwe ................................................................................................43
Nic o nas bez nas ...........................................................................................................................45
Co dwa algorytmy, to nie jeden .....................................................................................................48
Usuwaj bdy jak najwczeniej......................................................................................................52

Rozdzia 3. Ufortyfikuj swoje podsystemy ...................................................59

Jest bd, nie ma bdu ...................................................................................................................60
Zutylizuj swoje mieci ...................................................................................................................62
Jestem ju gdzie indziej .................................................................................................................66
Kontroluj wykorzystanie pamici ..................................................................................................69
Spjrz na to, czego nie wida ........................................................................................................72
Wybieraj rozsdnie ........................................................................................................................76
Szybki czy bezbdny ....................................................................................................................77
Teraz lub pniej ...........................................................................................................................77

NIEZAWODNO OPROGRAMOWANIA

Rozdzia 4. Jak wykonuje si Twj kod .......................................................81

Uwiarygodnij swj kod..................................................................................................................82
Przetestuj wszystkie rozgazienia.................................................................................................83
ywotne znaczenie przepywu danych ..........................................................................................85
Czy czego nie przeoczye ...........................................................................................................87
Sprbuj, a polubisz ........................................................................................................................88

Rozdzia 5. Niekomunikatywne interfejsy ...................................................91

getchar() zwraca liczb, nie znak...................................................................................................92
realloc() a gospodarka pamici ....................................................................................................94
Uniwersalny meneder pamici.....................................................................................................96
Nieprecyzyjne parametry ...............................................................................................................98
Faszywy alarm ............................................................................................................................101
Czytanie pomidzy wierszami .....................................................................................................103
Ostrzegaj przed niebezpieczestwem ..........................................................................................105
Diabe tkwi w szczegach ..........................................................................................................108

Rozdzia 6. Ryzykowny biznes ....................................................................111

int intowi nierwny ......................................................................................................................112
Nadmiar i niedomiar ....................................................................................................................116
Projekt czy prawie projekt ....................................................................................................118
Po prostu robi, co do nich naley ...............................................................................................120
Przecie to to samo ......................................................................................................................124
?: to take if..................................................................................................................................125
Precz z redundancj .....................................................................................................................128
Wysokie ryzyko, bez odwrotu .....................................................................................................129
Przeklta niespjno...................................................................................................................133
Nie przypisuj zmiennym informacji diagnostycznych ................................................................135
Nie warto ryzykowa ...................................................................................................................137

Rozdzia 7. Dramaturgia rzemiosa ............................................................141

Szybko, szybko .....................................................................................................................142
Zodziej otwierajcy zamek kluczem nie przestaje by zodziejem ............................................144
Kademu wedug potrzeb ............................................................................................................146
Nie uzewntrzniaj prywatnych informacji...................................................................................148
Funkcje-pasoyty .........................................................................................................................150
Programistyczne rubokrty ........................................................................................................153
Syndrom APL ..............................................................................................................................155
Bez udziwnie, prosz .................................................................................................................156
Na mietnik z tymi wszystkimi trikami .......................................................................................158

Rozdzia 8. Reszta jest kwesti nawykw...................................................163

Hokus-pokus, nie ma bdu .........................................................................................................163
Zrb dzi, co masz zrobi jutro....................................................................................................165
Doktora!!! ....................................................................................................................................166
Jeli dziaa, nie poprawiaj ............................................................................................................167
Funkcja z wozu, koniom lej .......................................................................................................169
Elastyczno rodzi bdy .............................................................................................................169
Sprbuj.........................................................................................................................................171
wity Harmonogram ..................................................................................................................172
Tester nazwa w sam raz dla testera .....................................................................................173
Programista zawini, testera powiesili .........................................................................................175
Zdefiniuj swe priorytety...............................................................................................................176

SPIS TRECI

Epilog.............................................................................................................181
Dodatek A Lista kontrolna kodowania ......................................................183
Dodatek B Podprogramy zarzdzania pamici .......................................189
Dodatek C Odpowiedzi ................................................................................197
Skorowidz......................................................................................................225

JAK WYKONUJE SI TWJ KOD

81

Omawiane w poprzednich rozdziaach metody automatycznego wykrywania

bdw asercje, testy integralnoci podsystemw, itp. stanowi narzdzia
niezwykle uyteczne i znaczenie ich naprawd trudno przeceni, jednake w niektrych przypadkach okazuj si one zupenie nieczue na bdy wystpujce w
testowanym kodzie. Przyczyna tego stanu rzeczy jest tyle oczywista, co banalna;
wyjanijmy j na (bliskim kademu z nas) przykadzie zabezpieczenia domu czy
mieszkania.
Ot najbardziej nawet wymylne zabezpieczenie drzwi i okien okae si zupenie nieprzydatne w sytuacji, gdy zodziej dostanie si do domu np. przez klap
w dachu, czy te otworzy sobie drzwi dorobionym kluczem. Podobnie, najwraliwszy nawet czujnik wstrzsowy zamontowany skrycie w magnetowidzie czy
komputerze nie uchroni przez kradzie np. drogocennej kolekcji obrazw. W
obydwu tych przypadkach zagroenie pojawia si bowiem poza obszarami, na monitorowanie ktrych zorientowane s urzdzenia alarmowe.
Na identycznej zasadzie, najbardziej nawet wymylne asercje, czy jeszcze bardziej zaawansowane fragmenty kodu testujce wystpowanie spodziewanych warunkw, s co warte jedynie wtedy, gdy w ogle zostaj wykonane! Brak alarmu
ze strony okrelonej asercji niekoniecznie wiadczy o spenieniu testowanego przez
t asercj warunku, ale moe by take wynikiem jej pominicia; podobnie punkt
przerwania spowoduje zatrzymanie wykonywania programu jedynie wtedy, gdy
wykonana zostanie instrukcja, na ktrej punkt ten ustawiono.
Wyjania to poniekd, dlaczego niektre bdy potrafi skutecznie wymyka
si (niczym sprytne szczury) najgstszej nawet sieci asercji czy punktw przerwa,
ktre tym samym stanowi tylko dodatkowy kopot dla programisty, a take powoduj dodatkow komplikacj i tak przewanie ju zoonego kodu.

81

82

NIEZAWODNO OPROGRAMOWANIA

Uciekajc si do maej metafory skoro nie potrafimy schwyta grubego

zwierza w puapk, warto pody jego ladem; skoro sterowanie w naszym programie omija ustanowione punkty przerwa i asercje, sprbujmy przeledzi jego
przebieg. Praca krokowa na poziomie zarwno kodu rdowego, jak i instrukcji
maszynowych jest jedn z podstawowych funkcji kadego debuggera, jest te wbudowana w znakomit wikszo wspczesnych rodowisk projektowych.

UWIARYGODNIJ SWJ KOD

Opracowywaem kiedy podprogram wykonujcy specyficzn funkcj na potrzeby
wikszego projektu (rodowiska programistycznego na Macintoshu). Podczas jego
rutynowego testowania znalazem pewien bd; jego konsekwencje dla innego
fragmentu wspomnianego projektu byy tak powane, i pozostawao dla mnie zagadk, dlaczego nie zosta on dotd wykryty, skoro powinien zamanifestowa si
w sposb oczywisty.
Spotkaem si wic z autorem wspomnianego fragmentu i pokazaem mu
bdny fragment swojego kodu. Gdy take wyrazi swe zdziwienie z powodu niewykrycia widocznego jak na doni bdu, postanowilimy ustawi punkt przerwania w krytycznym miejscu kodu, a po zatrzymaniu ktre naszym zdaniem musiao nastpi kontynuowa wykonywanie w sposb krokowy.
Zaadowalimy nasz projekt, kliknlimy przycisk Run i... ku naszemu zdumieniu program wykona si w caoci, bez zatrzymania! Wyjaniao to skdind,
dlaczego bd nie zosta zauwaony, lecz samo w sobie nadal pozostawao rzecz
zagadkow.
Ostatecznie przyczyna caego zamieszania okazaa si by prozaiczna: po prostu optymalizujcy kompilator wyeliminowa z kodu rdowego instrukcje, ktre
uzna za zbdne; instrukcja, na ktrej ustawilimy punkt przerwania miaa nieszczcie nalee do tego zestawu. Wykonanie kodu rdowego krok po kroku (czy
raczej prba takiego wykonania) uwidocznioby ten fakt w sposb nie budzcy
wtpliwoci.
Jako kierownik projektu, nalegam na programistw, by krokowe wykonywanie tworzonego przez nich kodu stanowio integralny element jego testowania
i, niestety, nazbyt czsto spotykam si ze stwierdzeniem, e przecie jest to
czynno czasochonna i jako taka spowoduje wyduenie pracy nad projektem.
To jednak tylko maa cz prawdy: po pierwsze dodatkowy czas przeznaczony na krokowe testowanie kodu jest tylko drobnym uamkiem czasu przeznaczonego na stworzenie tego kodu; po drugie uruchomienie programu w trybie
pracy krokowej nie jest w niczym trudniejsze od normalnego uruchomienia, bowiem rnica tkwi zazwyczaj jedynie w... nacinitych klawiszach; po trzecie (i
najwaniejsze) czas spdzony nad testowaniem programu stanowi swego rodzaju inwestycj w przeciwiestwie do czasu spdzonego na walk z trudnymi
do wykrycia bdami, stanowicego przykr konieczno. W jednym z poprzednich rozdziaw, piszc o testowaniu metod czarnej skrzynki, wyjaniaem niebagateln rol programowania defensywnego w walce z bdami moliwo
obserwacji zachowania si wasnego kodu dodatkowo zwiksza przewag programisty nad testerem obserwujcym jedynie przetwarzanie danych przez czarn skrzynk. ledzenie stworzonego (lub zmienionego) przez programist kodu powinno za-

JAK WYKONUJE SI TWJ KOD

83

tem sta si nieodcznym elementem jego pracy i cho moe pocztkowo uciliwe z czasem bdzie po prostu poytecznym nawykiem.

Nie odkadaj testowania krokowego do czasu, gdy pojawi si bdy.

PRZETESTUJ WSZYSTKIE ROZGAZIENIA

Praca krokowa, jak wszelkie inne narzdzia, moe wykazywa zrnicowan skuteczno w zalenoci od tego, jak umiejtnie jest stosowana. W szczeglnoci testowanie kodu zwiksza prawdopodobiestwo uniknicia bdw tylko wtedy, jeeli
przetestuje si cay kod; niestety, w przypadku pracy krokowej sterowanie poda
ciek wyznaczon przez zachodzce aktualnie warunki mowa tu oczywicie o
instrukcjach warunkowych, instrukcjach wyboru i wszelkiego rodzaju ptlach. Aby
wic przetestowa wszystkie moliwe rozgazienia, naley przeprowadzi testowanie przy np. rnych wartociach warunkw instrukcji
, czy selektorw instrukcji 
.
Notabene pierwszymi ofiarami niedostatecznego testowania padaj te fragmenty kodu, ktre wykonywane s bardzo rzadko lub wcale do tej ostatniej kategorii nale m.in. wszelkiego rodzaju procedury obsugujce bdy. Przyjrzyjmy
si poniszemu fragmentowi:

 
 



 










Kada zmiana jest niebezpieczna

Programici czsto pytaj, jaki jest sens testowania kadej zmiany kodu spowodowanej wzbogaceniem programu w nowe moliwoci. Na tak postawione pytanie
mona odpowiedzie jedynie innym pytaniem czy wprowadzone zmiany na
pewno, bez adnych wtpliwoci, wolne s od jakichkolwiek bdw? To prawda,
i przeledzenie kadego nowego (lub zmodyfikowanego) fragmentu kodu wymaga troch czasu, lecz jednoczenie fakt ten staje si nieoczekiwanie przyczyn interesujcego sprzenia zwrotnego mianowicie programici przywykli do konsekwentnego ledzenia wasnego kodu wykazuj tendencj do pisania krtkich i
przemylanych funkcji, bowiem doskonale wiedz, jak kopotliwe jest ledzenie
funkcji rozwlekych, pisanych bez zastanowienia.
Nie naley take zapomina o tym, by przy wprowadzaniu zmian do kodu ju
przetestowanego zmiany te naleycie wyrnia. Wyrniamy w ten sposb te
fragmenty, ktre istotnie wymagaj testowania; w przeciwnym razie kada zmiana
kodu moe pozbawi istniejcy kod wiarygodnoci uzyskanej drog czasochonnego testowania niczym odrobina ci zdolnej zepsu beczk miodu.

83

84

NIEZAWODNO OPROGRAMOWANIA

W prawidowo dziaajcym programie wywoanie funkcji 

 powoduje
przydzielenie tu 32-bajtowego bloku pamici i zwrcenie niezerowego wskanika,
zatem blok uwarunkowany instrukcj
 nie zostaje wykonany. Aby go naprawd
przetestowa, naley zasymulowa bdn sytuacj, czyli zastpi wartoci  
dopiero co przypisany wskanik:

 
 


 


 







Spowoduje to co prawda wyciek pamici wywoany utrat wskazania na przydzielony blok, jednake na etapie testowania zazwyczaj mona sobie na to pozwoli;
w ostatecznoci mona wykona wyzerowanie wskanika zamiast wywoywania
funkcji 

:

 
 


 


 







Na podobnej zasadzie naley przetestowa kad ze cieek wyznaczonych

przez instrukcje
 z fraz 
, instrukcje 
, jak rwnie operatory ,  i
.

Pamitaj o przetestowaniu kadego rozgazienia w programie.

YWOTNE ZNACZENIE PRZEPYWU DANYCH

Pierwotna wersja stworzonej przeze mnie funkcji , prezentowanej
w rozdziale 2., wygldaa nastpujco:
  

! ! " # " 

 
 
 


" $  " %&' &

() *) )*
 
++,-
++./-
++0-

JAK WYKONUJE SI TWJ KOD

85


 
 )*

)*
!! " ,

 "   " 1,

2& 
" 33$4

55 
' (')




Sprawdziem jej dziaanie w tworzonej aplikacji wyzerowujc fragmenty pamici o rnej wielkoci, zarwno wikszej, jak i mniejszej od zaoonego progu


. Wszystko przebiegao zgodnie z oczekiwaniami; wiedzc jednak o
tym, i zero jest wartoci w pewnym sensie wyjtkow, dla nadania testowi wikszej wiarygodnoci uyem w charakterze wypeniacza innego wzorca arbitralnie wybranej wartoci . Dla blokw mniejszych ni 

 wszystko byo nadal w naleytym porzdku, jednak dla wikszych blokw warto nadana
zmiennej l w linii
 
++,-
++./-
++0-

rwna bya  zamiast spodziewanej .

Rzut oka na asemblerow posta wygenerowanego kodu natychmiast ujawni
rzeczywist przyczyn takiego stanu rzeczy ot kompilator, ktrego uywaem, prowadzi obliczenia wyrae cakowitoliczbowych w arytmetyce 16-bitowej,
uwzgldniajc jedynie 16 najmniej znaczcych bitw wyrae  ! i
"!, czyli po prostu warto zero. W zmiennej
zapisywaa si jedynie bitowa alternatywa wyrae  i #!.

A co z czujnoci kompilatora ?
No wanie. Kod prezentowany w niniejszej ksice przetestowaem osobicie
uywajc piciu rnych kompilatorw; aden z nich, mimo ustawienia diagnostyki na najwyszym moliwym poziomie, nie ostrzeg mnie, i wspomniane instrukcje przesuwajce 16-bitow warto o 16, czy 24 bity powoduj utrat wszystkich
znaczcych bitw. Co prawda kompilowany kod zgodny by w zupenoci ze standardem ANSI C, jednake wynik wspomnianych konstrukcji niemal zawsze odbiega od oczekiwa programisty dlaczego wic brak jakichkolwiek ostrzee?
Prezentowany przypadek wykazuje jednoznacznie konieczno nacisku na producentw kompilatorw, by tego rodzaju opcje pojawiay si w przyszych wersjach
ich produktw. Zbyt czsto my, jako uytkownicy, nie doceniamy siy swej argumentacji w tym wzgldzie...
Ten subtelny bd zostaby niewtpliwie szybko wykryty przez testerw, chociaby ze wzgldu na widoczne konsekwencje (czyli wypenianie duych blokw
deseniem  zamiast ), jednake powicenie zaledwie kilku minut
na przeledzenie kodu pozwolio wykry w bd ju na etapie tworzenia funkcji.
Jak pokazuje powyszy przykad, krokowe wykonywanie kodu rdowego
moe nie tylko wskaza przepyw sterowania, lecz take uwidoczni inny, niesamowicie wany czynnik, mianowicie zmian wartoci poszczeglnych zmiennych

85

86

NIEZAWODNO OPROGRAMOWANIA

programu w rezultacie wykonywania poszczeglnych instrukcji co nazywane

bywa skrtowo przepywem danych. Moliwo spojrzenia na stworzony kod pod
ktem przepywu danych stanowi dodatkowy or dla programisty zastanw
si, ktre z poniszych bdw mog zosta dziki temu wykryte i nie s moliwe
do wykrycia w inny sposb:
nadmiar lub niedomiar;
bd konwersji danych;
bd pomyki o jedynk (patrz rozdzia 1.);
adresowanie za pomoc zerowych wskanikw;
odwoanie do nieprzydzielonych lub zwolnionych obszarw pamici (bd
A3, patrz rozdzia 3.);
pomykowe uycie operatora $ zamiast $$;
bd pierwszestwa operatorw;
bdy logiczne.
Przywoajmy raz jeszcze bdn instrukcj z rozdziau 1.:

& 676
89
)%


pomykowe uycie operatora $ moe by tu atwo przeoczone, jednak zaobserwowana zmiana wartoci zmiennej  wskutek wykonania instrukcji bd ten natychmiast demaskuje.

Podczas pracy krokowej programu

zwracaj szczegln uwag na przepyw danych.

CZY CZEGO NIE PRZEOCZYE

Obserwujc przepyw danych podczas pracy krokowej, nie jeste jednak w stanie
wykry wszystkich bdw. Przyjrzyjmy si poniszemu fragmentowi:
: ;  ) : 2<" ='
' " )(:> 
(2'")" ==?(&"2 ':>: *)"2<!
"2): )=?(&



@ A
3$ ' @ 

B' C '

3$ ' 

3$ '  


JAK WYKONUJE SI TWJ KOD

87

Odwoanie si do pola %&'(  ma sens jedynie wtedy, gdy wskanik

%& jest niezerowy. W instrukcji
 powinnimy wic uy operatora  powodujcego czciowe wartociowanie koniunkcji (gdy pierwszy jej argument ma warto 
, drugi nie jest ju wartociowany), tymczasem uyty operator  powoduje wartociowanie kompletne, co przy zerowej wartoci wskanika %& moe
spowodowa (a w trybie chronionym spowoduje na pewno) bd adresowania.
Pomykowe uycie operatora  nie moe jednak zosta wykryte w warunkach krokowego ledzenia kodu rdowego, postrzegajcego w kod w rozbiciu na kompletne instrukcje lub linie, nie za na poszczeglne wyraenia. Podobnie rzecz si ma
z operatorami  oraz .

A co z optymalizacj przekadu?
Wzajemne dopasowanie instrukcji kodu rdowego i rozkazw asemblerowych
moe by znacznie utrudnione, gdy kompilator dokonuje optymalizacji przekadu.
Gwne przejawy optymalizacji to eliminacja zbdnego kodu oraz czne tumaczenie kilku ssiadujcych instrukcji kodu rdowego czyli zjawiska jak najmniej
podane w procesie ledzenia kodu. Znakomit wikszo kompilatorw mona
zmusi do poniechania optymalizacji na etapie testowania programu poprzez odpowiednie ustawienie opcji kompilacji, wielu programistw dostrzega w tym jednak przejaw nadmiernego rnicowania wersji testowej i handlowej produktu. Skoro jednak podstawowym zadaniem testowania jest wyapanie bdw, warto
zastosowa kady zabieg, ktry moe si przyczyni do pomylnego wykonania tego zadania.
W kadym razie warto zawsze przekona si, czy dla konkretnego programu
optymalizacja istotnie utrudnia ledzenie jego kodu by moe w ogle nie trzeba
bdzie jej wycza.
Poza wyjtkowo dokadnym sprawdzaniem skadni wspomnianych instrukcji
lub wywietlaniem wartoci poszczeglnych wyrae (podczas pracy krokowej)
jedynym sposobem wykrycia opisanego bdu jest przeledzenie wykonania programu na poziomie instrukcji asemblera. Wymaga to niewtpliwie kwalifikacji potrzebnych do skojarzenia rozkazw maszynowych z odpowiadajcymi im instrukcjami kodu rdowego, jednak takie bdy jak adresowanie z uyciem
wyzerowanego rejestru segmentowego staj si natychmiast widoczne.

ledzenie kodu rdowego musi by niekiedy uzupenione

ledzeniem wygenerowanego przekadu.

SPRBUJ, A POLUBISZ
Niektrych programistw naprawd trudno skoni do systematycznego ledzenia
wasnych programw lub przynajmniej do sprbowania tego przez np. miesic.
Wymawiaj si brakiem czasu, bd te niechci do jego tracenia. Uwaam, i

87

88

NIEZAWODNO OPROGRAMOWANIA

obowizkiem kadego kierownika projektu jest przekonanie takich opornych programistw, i taka oszczdno jest oszczdnoci zdecydowanie le pojt, gdy
oznacza ryzyko tracenia (w przyszoci) znacznie wikszej iloci czasu na tropienie
bdw w gotowym kodzie, przede wszystkim wanie za pomoc ledzenia krokowego. Myl, e tre niniejszego rozdziau (jak i pozostaych rozdziaw niniejszej
ksiki) dostarcza niezbdnych ku temu argumentw.
Zreszt jeli po przeamaniu pocztkowej niechci podejmie si prb ledzenia stworzonego wanie kodu i skonstatuje, e wiele tkwicych w nim bdw
mona z atwoci wyapa i usun ju w cigu dziesiciu minut, dalsze argumenty okazuj si zbyteczne. W taki oto sposb pocztkowa nieufno ustpuje
miejsca poytecznym nawykom...

PODSUMOWANIE
Bdy nie pojawiaj si znikd, lecz s przyrodzonym elementem kadego nowo tworzonego kodu, bd efektem wprowadzanych do tego kodu modyfikacji.
Wyjania to, dlaczego ledzenie wykonania takich nowych kawakw stanowi
najskuteczniejsz bro w walce z bdami.
Obawy, i ledzenie kodu wymaga jakich ogromnych nakadw czasu, s cakowicie nieuzasadnione. ledzenie kodu trwa na pewno znacznie krcej od jego tworzenia, poza tym z zasady pozwala unikn niepotrzebnej straty czasu
zwizanej z pniejszym wyszukiwaniem bdw w gotowym programie.
ledzenie kodu jest operacj w peni skuteczn jedynie wtedy, gdy ledzeniu
podlegaj wszystkie rozgazienia w kodzie. Naley o tym pamita przy ledzeniu instrukcji warunkowych, ptli oraz wyrae zawierajcych operatory
,  i .
W niektrych przypadkach ledzenie kodu rdowego musi by uzupenione
ledzeniem wygenerowanego przekadu w celu zorientowania si, jak w rzeczywistoci przebiega wykonanie konkretnej instrukcji. Konieczno taka nie
zdarza si co prawda zbyt czsto, lecz jeeli faktycznie zaistnieje, nie naley
jej lekceway.
PROJEKT: W rozdziale 1. przedstawiem przykady najczciej wystpujcych
bdw programistycznych oraz pytanie o moliwo automatycznego wykrywania
ich przez kompilatory. Zastanw si, w jakim stopniu krokowe ledzenie kodu moe
zwikszy szans wykrywania ich przez programist.
PROJEKT: Sporzd list bdw programistycznych popenionych przez Ciebie
w cigu ostatnich szeciu miesicy i zastanw si, ilu z nich mona byo zapobiec
przez systematyczne ledzenie stworzonego kodu.