— . Klasa to w standardzie języka C++
równie niesławny przykład monolitycznego projektu klasy. Klasa ta została rozepchana zbyt wielką liczbą (nawet użytecznych i przyjemnych) dodatków — przez to, choć aspiruje do miana kontenera, nie jest nim do końca, nie może bowiem wybrać pomiędzy indeksowaniem a iteracją i równocześnie powiela wiele standardowych algorytmów, nie zostawiając za to za wiele miejsca na rozszerzenia (patrz przykład do wytycznej 44.).
Źródła
[Henney02a] [Henney02b] [McConnell93] §10.5 [Stroustrup00] §3.8, §4.9.4,
§23.4.3.1 [Sutter00] §10, §12, §19, §23 [Sutter02] §1 [Sutter04] §37–40
Wytyczna 6. Przede wszystkim poprawność, prostota i przejrzystość
31
Wytyczna 6.
Przede wszystkim poprawność,
prostota i przejrzystość
Wytyczna 6. Przede wszyst kim poprawność, pros tota i przejrzystość
Streszczenie
Wedle zasady KISS (Keep It Simple Software — parafraza Keep It Simple, Stupid, czyli
„jak najprościej, głupku”) im prościej, tym lepiej. Proste jest niemal zawsze lepsze od złożonego. Przejrzyste zaś jest lepsze od niejasnego. No i bezpieczne jest lepsze od niebezpiecznego (patrz wytyczne 83. i 99.).
Uzasadnienie
Trudno przecenić znaczenie prostoty projektu i przejrzystości kodu. Programista two-rzący kod czytelny i zrozumiały będzie cieszył się wdzięcznością ze strony przyszłego opiekuna tego kodu. Powinieneś przy tym pamiętać, że opiekę nad kodem często spra-wują jego twórcy i, mając to na uwadze, dbać o swoje samopoczucie w przyszłości.
Stąd klasyczne prawdy w rodzaju:
Programy muszą być pisane tak, aby dały się czytać przez ludzi, ewentualnie
od czasu do czasu wykonywać przez maszyny
— Harold Abelson i Gerald Jay Sussman
Pisz programy przede wszystkim dla ludzi, potem dla komputerów
— Steve McConnell
Najtańszymi, najszybszymi i najbardziej niezawodnymi komponentami
systemu komputerowego są te, których w nim nie ma
— Gordon Bell
Owe brakujące komponenty są również najdokładniejsze (nigdy się nie mylą),
najbezpieczniejsze (nie da się do nich włamać) i najprostsze w projektowaniu,
dokumentowaniu, testowaniu i konserwacji. Nie sposób przecenić prostoty
projektowej
— Jon Bentley
Wiele wytycznych prezentowanych w tej książce ma ukierunkować czytelnika na kod
i projekty łatwe w modyfikacji; przejrzystość i zrozumiałość to najbardziej pożądane cechy prostych w konserwacji i rozbudowie programów. Trudno zmienić to, czego się
nie rozumie.
Najsilniejsza sprzeczność zachodzi pomiędzy przejrzystością kodu a jego optymaliza-cją (patrz wytyczne 7., 8. i 9.). Kiedy (a nie jeżeli!) staniesz w obliczu pokusy przedwczesnej optymalizacji kodu pod kątem wydajności, a kosztem przejrzystości, przy-pomnij sobie sens wytycznej 8. — dużo łatwiej jest przyspieszyć poprawny program,
niż poprawić szybki.
32
Rozdział 2. Styl projektowy
Unikaj więc „zaułków” języka programowania i stosuj zawsze najprostsze z efektyw-
nych technik.
Przykłady
Przykład 1. — unikaj zbędnego (choć efektownego) przeciążania operatorów. Jedna
z (niepotrzebnie) udziwnionych bibliotek graficznego interfejsu użytkownika wyma-gała, celem dodania do widgetu elementu sterującego , napisania wyrażenia
(zobacz wytyczną 26.).
Przykład 2. — w roli parametrów konstruktorów stosuj zmienne nazwane, nie tymcza-
sowe. Pozwala to na uniknięcie niejednoznaczności deklaracji. Pozwala też na lepszą prezentację zadania realizowanego przez kod i tym samym uproszczenie konserwacji
programu. Jest też niejednokrotnie bezpieczniejsze (zobacz wytyczne 13. i 31.).
Źródła
[Abelson96] [Bentley00] §4 [Cargill92] pp.91–93 [Cline99] §3.05–06 [Constan-tine95] §29 [Keffer95] p. 17 [Lakos96] §9.1, §10.2.4 [McConnell93] [Mey-
ers01] §47 [Stroustrup00] §1.7, §2.1, §6.2.3, §23.4.2, §23.4.3.2 [Sutter00] §40–41,
§46 [Sutter04] §29
Wytyczna 7. Jak i kiedy kodować z uwzględnieniem skalowalności
33
Wytyczna 7.
Jak i kiedy kodować
z uwzględnieniem skalowalności
Wytyczna 7. Jak i kiedy kodować z uw zg lędnieniem s kalowalno ści
Streszczenie
Wystrzegaj się wybuchowego rozrostu kodu — unikając przedwczesnej optymalizacji,