Pokrewne
- Strona Główna
- May Karol Grobowiec Rodrigandow (SCAN dal
- Lackey Mercedes Obietnica Magii
- Hobb Robin Krolewski Skrytobojca (SCAN dal
- Dick Philip K Czlowiek o jednakowych zebach (
- Cervantes Saavedra de Miguel Niezwykłe przygody Don Kichota z la Manchy
- Petersin Thomas Ogrodnik Szoguna
- Lofting Hugh Ogrod zoologiczny doktora Dolit (2)
- Zdzis aw Iwulski WYZNACZANIE SI TN CYCH I MOMENT W ZGINAJ
- Norton Andre Na skrzydlach Magii (SCAN dal 1
- Chmielewska Joanna Zbieg okolicznosci (SCAN dal 10
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- streamer.htw.pl
[ Pobierz całość w formacie PDF ]
.Jeżelibowiem dany fragment kodu faktycznie produkuje żądane wyniki, fakt ten musibyć widoczny w sposób oczywisty.W kodzie, którego poprawność jest w jakimśstopniu zakamuflowana, mogą bowiem czaić się równie głęboko zakamuflowanebłędy.I to właśnie jest najważniejszym powodem tworzenia kodu prostego, łatwegodo zrozumienia, pozbawionego efektownych wodotrysków.Postępując zgodniez tą ideą ułatwiasz pracę i sobie, i innym.PODSUMOWANIEf& Nie zapisuj danych (nawet tymczasowo) do pamięci, która nie jest przydzielo-na do Twojego programu.Jeżeli sądzisz, że odczytywanie danych z takiej pa-mięci może być sensowne, przypomnij sobie kłopoty z kopiowaniem pomię-dzy komórkami pamięci wejścia-wyjścia.f& Nie odwołuj się do bloku pamięci po jego zwolnieniu jego zawartość mogłaulec zniszczeniu przez inne programy lub procedury zarządzające pamięcią.f& Przekazywanie danych za pomocą globalnych buforów może być niekiedyuzasadnione względami efektywności, lecz wiąże się z wieloma trudnościami.Tworzone przez wywoływaną funkcję dane, użyteczne dla funkcji wywołują-cej, powinny być przekazywane bezpośrednio do tej ostatniej.Jeżeli jednak danete rezydują w globalnych buforach, należy chronić je przed zniszczeniem tak dłu-go, jak długo są potrzebne.f& Nie uzależniaj poprawnego działania tworzonej funkcji od konkretnych szcze-gółów implementacyjnych innych funkcji.C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.doc 155156 NIEZAWODNOZ OPROGRAMOWANIAf& Używaj języka programowania zgodnie z przeznaczeniem, posługując się jegonaturalnymi konstrukcjami i unikając niejasnych idiomów nawet wówczas,gdy standardy języka gwarantują ich poprawne działanie.Pamiętaj, iż standar-dy nie są wieczne i mogą się zmieniać.f& To nieprawda, iż zwięzłe konstrukcje językowe powodują generowanie równiezwięzłego przekładu.Należy więc dobrze się zastanowić przed przystąpieniemdo przekształcania czytelnej instrukcji, zajmującej kilka linii kodu w nieczytel-ną konstrukcję mieszczącą się w jednej linii.Efektywność przekładu może nicna tym nie zyskać i przysłowiowa skórka okaże się niewarta wyprawki.f& Unikaj tworzenia kodu przypominającego kontrakty pisane przez prawników nie można wymagać, by zrozumienie programu wymagało kwalifikacji eksper-ta; musi on być zrozumiały przez przeciętnego programistę.POMYZL O TYM1.Programiści bardzo często modyfikują argumenty wywołania funkcji (w jejtreści przyp.tłum.).Dlaczego nie kłóci się to z implikowanymi regułami do-stępu do danych wejściowych?2.Pamiętając o ryzyku związanym z używaniem globalnego bufora przez funkcjęstrFromUns zastanów się, czy poniższa wersja używająca globalnego wskaz-nika stwarza jakieś dodatkowe niebezpieczeństwo?char *strFromUns(unsigned u);{static char *strDigits = '?????';char *pch/* jeśli u znajduje się poza zakresem, użyj UlongToStr */ASSERT(u 0);return(pch);}3.Napotkałem kiedyś kod dokonujący szybkiego zerowania wszystkich zmien-nych lokalnych w następujący sposób:void DoSomething(.){int i;int j;int k;156 C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.docDRAMATURGIA RZEMIOSAA 157memset(&k, 0, 3*sizeof(int)); /* wyzeruj i, j oraz k */&}Ten kod może poprawnie funkcjonować w niektórych implementacjach, alepodobnych konstrukcji należy generalnie unikać.Dlaczego?4.Mimo iż część systemu operacyjnego komputera może być zapisana w pamięcitylko do odczytu, bezpośrednie odwoływanie się do tej pamięci z pominięcieminterfejsu systemowego niesie ze sobą pewne ryzyko.Dlaczego?5.Język C umożliwia pomijanie niektórych argumentów funkcji w jej wywołaniu,na przykład:.DoOperation(opNegAcc); /* nie ma potrzeby przekazywania* argumentu "val"*/.void DoOperation(operation op, int val){switch (op){case opNegAcc:accumulator = - accumulator;break;case opAddVal:accumulator += val;break;.}Dlaczego mimo wszystko nie należy tej możliwości wykorzystywać, mimo iżmoże ona poprawić efektywność programu?6.Co w istocie weryfikuje poniższa asercja i jaka jest jej bardziej czytelna po-stać?Przypomnij sobie poniższy fragment funkcji memmove:((pbTo > pbFrom) ? tailmove : headmove)(pbTo, pbFrom, size);W jaki sposób poprawić jej czytelność, z zachowaniem koncepcji prezento-wanej przez autora?7.Poniższy fragment w języku asemblera pokazuje najczęstszy sposób wywoły-wania funkcji.Na czym polega ryzyko związane z tego rodzaju konstrukcja-mi?C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.doc 157158 NIEZAWODNOZ OPROGRAMOWANIAmove r0,#PRINTERcall Print+4.Print: move r0,#DISPLAY ; (instrukcja 4-bajtowa); r0 zawiera identyfikator urządzenia.8.Poniższy fragment kodu, podobnie jak fragment z poprzedniego ćwiczenia,zależny jest od wewnętrznej implementacji funkcji Print, lecz ma poza tymjeszcze jedną niepożądaną cechę.Jaką?instClearR0 = 0x36A2 ; kod zerujący rejestr r0.call Print+2 ; wyjście na drukarkę.Print: move r0,#instClearR0 ; (instrukcja 4-bajtowa)comp r0,#0 ; 0 - drukarka, `" 0 ekran.158 C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.doc [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl agnieszka90.opx.pl
.Jeżelibowiem dany fragment kodu faktycznie produkuje żądane wyniki, fakt ten musibyć widoczny w sposób oczywisty.W kodzie, którego poprawność jest w jakimśstopniu zakamuflowana, mogą bowiem czaić się równie głęboko zakamuflowanebłędy.I to właśnie jest najważniejszym powodem tworzenia kodu prostego, łatwegodo zrozumienia, pozbawionego efektownych wodotrysków.Postępując zgodniez tą ideą ułatwiasz pracę i sobie, i innym.PODSUMOWANIEf& Nie zapisuj danych (nawet tymczasowo) do pamięci, która nie jest przydzielo-na do Twojego programu.Jeżeli sądzisz, że odczytywanie danych z takiej pa-mięci może być sensowne, przypomnij sobie kłopoty z kopiowaniem pomię-dzy komórkami pamięci wejścia-wyjścia.f& Nie odwołuj się do bloku pamięci po jego zwolnieniu jego zawartość mogłaulec zniszczeniu przez inne programy lub procedury zarządzające pamięcią.f& Przekazywanie danych za pomocą globalnych buforów może być niekiedyuzasadnione względami efektywności, lecz wiąże się z wieloma trudnościami.Tworzone przez wywoływaną funkcję dane, użyteczne dla funkcji wywołują-cej, powinny być przekazywane bezpośrednio do tej ostatniej.Jeżeli jednak danete rezydują w globalnych buforach, należy chronić je przed zniszczeniem tak dłu-go, jak długo są potrzebne.f& Nie uzależniaj poprawnego działania tworzonej funkcji od konkretnych szcze-gółów implementacyjnych innych funkcji.C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.doc 155156 NIEZAWODNOZ OPROGRAMOWANIAf& Używaj języka programowania zgodnie z przeznaczeniem, posługując się jegonaturalnymi konstrukcjami i unikając niejasnych idiomów nawet wówczas,gdy standardy języka gwarantują ich poprawne działanie.Pamiętaj, iż standar-dy nie są wieczne i mogą się zmieniać.f& To nieprawda, iż zwięzłe konstrukcje językowe powodują generowanie równiezwięzłego przekładu.Należy więc dobrze się zastanowić przed przystąpieniemdo przekształcania czytelnej instrukcji, zajmującej kilka linii kodu w nieczytel-ną konstrukcję mieszczącą się w jednej linii.Efektywność przekładu może nicna tym nie zyskać i przysłowiowa skórka okaże się niewarta wyprawki.f& Unikaj tworzenia kodu przypominającego kontrakty pisane przez prawników nie można wymagać, by zrozumienie programu wymagało kwalifikacji eksper-ta; musi on być zrozumiały przez przeciętnego programistę.POMYZL O TYM1.Programiści bardzo często modyfikują argumenty wywołania funkcji (w jejtreści przyp.tłum.).Dlaczego nie kłóci się to z implikowanymi regułami do-stępu do danych wejściowych?2.Pamiętając o ryzyku związanym z używaniem globalnego bufora przez funkcjęstrFromUns zastanów się, czy poniższa wersja używająca globalnego wskaz-nika stwarza jakieś dodatkowe niebezpieczeństwo?char *strFromUns(unsigned u);{static char *strDigits = '?????';char *pch/* jeśli u znajduje się poza zakresem, użyj UlongToStr */ASSERT(u 0);return(pch);}3.Napotkałem kiedyś kod dokonujący szybkiego zerowania wszystkich zmien-nych lokalnych w następujący sposób:void DoSomething(.){int i;int j;int k;156 C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.docDRAMATURGIA RZEMIOSAA 157memset(&k, 0, 3*sizeof(int)); /* wyzeruj i, j oraz k */&}Ten kod może poprawnie funkcjonować w niektórych implementacjach, alepodobnych konstrukcji należy generalnie unikać.Dlaczego?4.Mimo iż część systemu operacyjnego komputera może być zapisana w pamięcitylko do odczytu, bezpośrednie odwoływanie się do tej pamięci z pominięcieminterfejsu systemowego niesie ze sobą pewne ryzyko.Dlaczego?5.Język C umożliwia pomijanie niektórych argumentów funkcji w jej wywołaniu,na przykład:.DoOperation(opNegAcc); /* nie ma potrzeby przekazywania* argumentu "val"*/.void DoOperation(operation op, int val){switch (op){case opNegAcc:accumulator = - accumulator;break;case opAddVal:accumulator += val;break;.}Dlaczego mimo wszystko nie należy tej możliwości wykorzystywać, mimo iżmoże ona poprawić efektywność programu?6.Co w istocie weryfikuje poniższa asercja i jaka jest jej bardziej czytelna po-stać?Przypomnij sobie poniższy fragment funkcji memmove:((pbTo > pbFrom) ? tailmove : headmove)(pbTo, pbFrom, size);W jaki sposób poprawić jej czytelność, z zachowaniem koncepcji prezento-wanej przez autora?7.Poniższy fragment w języku asemblera pokazuje najczęstszy sposób wywoły-wania funkcji.Na czym polega ryzyko związane z tego rodzaju konstrukcja-mi?C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.doc 157158 NIEZAWODNOZ OPROGRAMOWANIAmove r0,#PRINTERcall Print+4.Print: move r0,#DISPLAY ; (instrukcja 4-bajtowa); r0 zawiera identyfikator urządzenia.8.Poniższy fragment kodu, podobnie jak fragment z poprzedniego ćwiczenia,zależny jest od wewnętrznej implementacji funkcji Print, lecz ma poza tymjeszcze jedną niepożądaną cechę.Jaką?instClearR0 = 0x36A2 ; kod zerujący rejestr r0.call Print+2 ; wyjście na drukarkę.Print: move r0,#instClearR0 ; (instrukcja 4-bajtowa)comp r0,#0 ; 0 - drukarka, `" 0 ekran.158 C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\r07.doc [ Pobierz całość w formacie PDF ]