[ Pobierz całość w formacie PDF ]
.Nawet jeżeli konstruowane w ten sposób nazwy trudne są do wymówienia, są one jednak wystarczające do tego, by w krótkiej nazwie zmiennej zawrzeć wystarczające informacje na temat jej typu.Nie tylko ułatwia to studiowanie programów, lecz umożliwia proste rozróżnienie pomiędzy zmiennymi różnych typów.Przykładowo parametrami funkcji bibliotecznej strcpy są dwa wskaźniki do znaku, zatem jeden z możliwych jej prototypów mógłby wyglądać następująco:char *strcpy(char *pchTo, char *pchFrom); /* prototyp */Ponieważ jednak obszary wskazywane przez wspomniane parametry nie są dowolnymi obszarami znakowymi, lecz łańcuchami z zerowymi ogranicznikami, sama zaś notacja węgierska przyczyniać się powinna do lepszego zrozumienia kodu, bardziej komunikatywny wydaje się tu zapis:char *strcpy(char *strTo, char *strFrom); /* prototyp */Nie inaczej ma się rzecz z nazwami funkcji i tablic — z jednym wszakże wyjątkiem: otóż zgodnie z oryginalną notacją węgierską nazwa funkcji powinna rozpoczynać się od wielkiej litery, lecz dla spójności prezentowanego kodu postanowiłem odstąpić od tej zasady i zastosować charakterystyczne dla typów przedrostki nazw funkcji na równi ze zmiennymi prostymi.Tak więc gdyby zapisać w notacji węgierskiej prototypy funkcji (przykładowo) malloc i realloc, mogłyby one wyglądać tak:void *pvNewBlock(size_t size); /* prototyp */void *pvResizeBlock(void *pv, size_t sizeNew); /* prototyp */Powróćmy jeszcze do nazw „zagnieżdżonych” wskaźników:*ppb = pbNew;Chociaż na pierwszy rzut oka może to wyglądać dziwnie, zauważ, iż „gwiazdki” mogą znosić się z sąsiadującymi literami p — stosując tę zasadę do powyższej instrukcji przypisania otrzymamy:pb = pbNew;czyli zgodną co do typów instrukcję przypisania.W analogiczny sposób redukować się mogą (z literami p) operatory & i ->.Spójrz na poniższe instrukcje:pb = &b;b = psym->bLength;W wyniku wspomnianej redukcji otrzymamy:b = b;b = sym.bLength;a więc przypisania bajtów do bajtów.I jeszcze jedno.Trudno co prawda podać taką definicję „błędu w programie”, która zadowoliłaby wszystkich Czytelników niniejszej książki, na jedną rzecz chciałbym wszakże zwrócić uwagę: należy odróżniać błędy wprowadzane (bezwiednie) przez programistę podczas tworzenia kodu od błędów pozostających w tym kodzie wówczas, gdy programista uzna go za (przypuszczalnie) bezbłędny — treść niniejszej książki koncentruje się na tej drugiej kategorii.Innymi słowy — trudno spodziewać się, by programiści produkowali bezbłędny kod każdorazowo, gdy tylko usiądą do klawiatury, lecz powinni dążyć do usunięcia wszystkich popełnionych przez siebie błędów przed scaleniem swego kodu z „głównymi” źródłami.XXXXXXXXXXStosowana w tej książce konwencja nazewnicza jest tak naprawdę tylko namiastką propozycji Ch.Simonyiego.Na podstawie reguł dotychczas przedstawionych nie sposób na przykład rozstrzygnąć, czy pch[] jest wskaźnikiem do tablicy znakowej, czy też tablicą wskaźników do znaków.Pełna specyfikacja konwencji węgierskiej jednoznacznie rozstrzyga takie i podobne wątpliwości; jeżeli jesteś zainteresowany jej szczegółami, zajrzyj do pracy doktorskiej Ch.Simonyiego dostępnej pod adresem:www.parc.xerox.com/publications/pubs-hst.html (rok 1976).Wśród programistów notacja węgierska nie cieszy się jednakowym poważaniem: jedni uważają ją za największy wynalazek od czasów programowania strukturalnego, inni — wręcz wyśmiewają.D.Knuth: „TEX: The Program”.14 Niezawodność oprogramowaniaWstęp 1314 D:\Roboczy\Niezawodność oprogramowania\9 po skladzie 1\r00-2.docD:\Roboczy\Niezawodność oprogramowania\9 po skladzie 1\r00-2.doc 13
[ Pobierz całość w formacie PDF ]