Język C++. Standardy kodowania. 101 zasad, wytycznych i zalecanych praktyk

Czytelny i przejrzysty kod to podstawa sprawnego tworzenia aplikacji. W przypadku pracy zespołowej stosowanie wspólnego standardu kodowania to konieczność. Pisanie kodu w oparciu o określone standardy kodowania przyspiesza powstawanie programu, ułatwia komunikację pomiędzy członkami zespołu i pozwala na szybkie wdrożenie nowych programistów do projektu. Oczywiście, w każdej firmie lub zespole można ustalić własny standard kodowania -- ważne jest jednak, aby opierał się na określonych regułach, wynikających ze specyfiki języka programowania.

Książka "Język C++. Standardy kodowania. 101 zasad, wytycznych i zalecanych praktyk" zawiera opis wspomnianych reguł. Przedstawia zasady pisania kodu źródłowego i standaryzowania określonych zapisów, operacji i sposobów wykorzystania elementów języka C++. Każda z zasad jest szczegółowo omówiona i poparta praktycznymi przykładami. Książka prezentuje najlepsze ze znanych praktyk -- zarówno "starych", jak i tych, które całkiem niedawno uległy standaryzacji, oraz opisuje techniki, o których nie słyszeli nawet programiści z wieloletnim doświadczeniem.

• Organizacja kodu
• Styl projektowy i styl kodowania
• Skalowalność kodu
• Racjonalna i efektywna obsługa błędów
• Prawidłowe stosowanie elementów języka
• Odpowiednie korzystanie z STL
• Bezpieczeństwo typów

Usprawnij pracę, stosując standardy kodowania -- gdy za parę miesięcy będziesz musiał wrócić do swoich dzisiejszych programów, przekonasz się, że było warto.

• Wytyczna 0. Nie bądź małostkowy (czyli czego nie standaryzować) (14)
• Wytyczna 1. Dbaj o bezbłędną kompilację przy najwyższym poziomie ostrzeżeń kompilatora (17)
• Wytyczna 2. Korzystaj z automatycznych systemów kompilacji (20)
• Wytyczna 3. Korzystaj z systemu kontroli wersji (22)
• Wytyczna 4. Nie oszczędzaj na wzajemnej rewizji kodu (24)

• Wytyczna 5. Jednej jednostce jedno zadanie (29)
• Wytyczna 6. Przede wszystkim poprawność, prostota i przejrzystość (31)
• Wytyczna 7. Jak i kiedy kodować z uwzględnieniem skalowalności (33)
• Wytyczna 8. Wystrzegaj się przedwczesnej optymalizacji (36)
• Wytyczna 9. Wystrzegaj się przedwczesnej pesymizacji (39)
• Wytyczna 10. Minimalizuj ilość danych globalnych i współużytkowanych (41)
• Wytyczna 11. Ukrywaj informacje (43)
• Wytyczna 12. Niepotrzebna rywalizacja to niezdrowa rywalizacja (45)
• Wytyczna 13. Zagwarantuj opiekę nad zasobami przez obiekty. Stosuj RAII i inteligentne wskaźniki (49)

• Wytyczna 14. Lepsze błędy kompilacji i konsolidacji od błędów czasu wykonania (54)
• Wytyczna 15. Nie bój się stosowania const (57)
• Wytyczna 16. Unikaj makrodefinicji (59)
• Wytyczna 17. Unikaj "magicznych numerków" (62)
• Wytyczna 18. Zmienne deklaruj najbardziej lokalnie, jak to możliwe (64)
• Wytyczna 19. Każda zmienna powinna zostać zainicjalizowana (66)
• Wytyczna 20. Unikaj rozwlekłych funkcji, wystrzegaj się głębokich zagnieżdżeń (69)
• Wytyczna 21. Unikaj zależności inicjalizacji w różnych jednostkach kompilacji (71)
• Wytyczna 22. Redukuj zależności definicyjne i unikaj zależności cyklicznych (73)
• Wytyczna 23. Niech pliki nagłówkowe będą samowystarczalne (75)
• Wytyczna 24. Pamiętaj o wewnętrznych barierach plików nagłówkowych, unikaj barier zewnętrznych (77)

• Wytyczna 25. Parametry przyjmować odpowiednio - przez wartość, (inteligentne) wskaźniki albo referencje (80)
• Wytyczna 26. Zachowuj naturalną semantykę przeciążanych operatorów (82)
• Wytyczna 27. Preferuj kanoniczne postaci operatorów arytmetycznych i przypisania (84)
• Wytyczna 28. Preferuj kanoniczne postaci operatorów ++ i -- oraz ich wersje przedrostkowe (86)
• Wytyczna 29. Przeciążanie w miejsce niejawnej konwersji typów (88)
• Wytyczna 30. Unikaj przeciążania operatorów &&, || i operatora , (przecinka) (90)
• Wytyczna 31. Nie uzależniaj poprawności kodu od kolejności ewaluacji argumentów wywołania funkcji (93)

• Wytyczna 32. Ustal rodzaj definiowanej klasy (96)
• Wytyczna 33. Lepsze klasy minimalistyczne niż monolityczne (98)
• Wytyczna 34. Lepsza kompozycja od dziedziczenia (100)
• Wytyczna 35. Nie dziedzicz po klasach, które nie zostały przewidziane jako bazowe (103)
• Wytyczna 36. O wyższości interfejsów abstrakcyjnych (106)
• Wytyczna 37. Dziedziczenie publiczne daje wymienialność (109)
• Wytyczna 38. Uprawiaj bezpieczne przesłanianie (111)
• Wytyczna 39. Niech metody wirtualne będą niepublicznymi, a publiczne - niewirtualnymi (114)
• Wytyczna 40. Unikaj udostępniania konwersji niejawnych (117)
• Wytyczna 41. Składowe klas, z wyjątkiem klas prostych agregatów, powinny być prywatne (120)
• Wytyczna 42. Nie trwonić tego, co własne (123)
• Wytyczna 43. Zachowaj umiar w implementacjach prywatnych (126)
• Wytyczna 44. Warto polubić zwykłe funkcje - nieskładowe i niezaprzyjaźnione (129)
• Wytyczna 45. Zawsze udostępniaj komplet: new razem z delete (131)
• Wytyczna 46. Jeśli przeciążać new dla klasy, to porządnie - z wszystkimi standardowymi formami operatora (133)

• Wytyczna 47. Porządek inicjalizacji składowych danych powinien być zgodny z porządkiem ich deklaracji (136)
• Wytyczna 48. W konstruktorze lepsza inicjalizacja od przypisania (138)
• Wytyczna 49. Unikaj wywołań metod wirtualnych w konstruktorach i destruktorach (140)
• Wytyczna 50. Destruktory klasy powinny być albo publiczne i wirtualne, albo niewirtualne i zabezpieczone (143)
• Wytyczna 51. Operacje destrukcji, dealokacji i podmiany nigdy nie zawodzą (146)
• Wytyczna 52. Usuwaj, co skopiujesz (149)
• Wytyczna 53. Jawnie udostępniaj i blokuj kopiowanie (151)
• Wytyczna 54. Unikaj skrawania obiektów - rozważ zastosowanie duplikacji w miejsce kopiowania w klasach bazowych (153)
• Wytyczna 55. Przyzwyczaj się do kanonicznych implementacji przypisania (156)
• Wytyczna 56. Tam, gdzie to zasadne, udostępniaj bezpieczną (niezgłaszającą wyjątków) operację podmiany (158)

• Wytyczna 57. Typ i nieskładowe funkcje jego interfejsu powinny rezydować w tej samej przestrzeni nazw (162)
• Wytyczna 58. Typy i funkcje, jeśli nie są przeznaczone do kooperacji, powinny być rozmieszczone w oddzielnych przestrzeniach nazw (165)
• Wytyczna 59. Wystrzegaj się deklaracji i dyrektyw using w plikach nagłówkowych i plikach kodu źródłowego przed dyrektywą #include (167)
• Wytyczna 60. Pamięć powinna być przydzielana i zwalniana w tym samym module (171)
• Wytyczna 61. Nie definiuj w plikach nagłówkowych jednostek podlegających łączeniu zewnętrznemu (173)
• Wytyczna 62. Nie pozwalaj na propagację wyjątków pomiędzy modułami (176)
• Wytyczna 63. Interfejs modułu powinien korzystać z dostatecznie przenośnych typów (179)

• Wytyczna 64. Łącz zalety polimorfizmu dynamicznego i statycznego (184)
• Wytyczna 65. Jeśli umożliwiać dostosowywanie, to celowo i jawnie (187)
• Wytyczna 66. Wystrzegaj się specjalizacji szablonów funkcji (192)
• Wytyczna 67. Unikaj przypadkowych uszczegółowień kodu w zamierzeniu uniwersalnego (195)

• Wytyczna 68. Asercje świetnie dokumentują wewnętrzne założenia i niezmienniki kodu (198)
• Wytyczna 69. Ustal racjonalne zasady obsługi błędów i ściśle ich przestrzegaj (201)
• Wytyczna 70. Odróżniaj błędy od stanów nimi nie będących (204)
• Wytyczna 71. Projektuj i pisz kod wolny od błędów (208)
• Wytyczna 72. Błędy najlepiej zgłaszać za pomocą wyjątków (212)
• Wytyczna 73. Zgłaszaj wartości, przechwytuj referencje (217)
• Wytyczna 74. Błędy trzeba właściwie sygnalizować, obsługiwać i tłumaczyć (219)
• Wytyczna 75. Unikaj specyfikacji wyjątków (221)

• Wytyczna 76. Domyślnie stosuj kontener vector. Inne dobieraj odpowiednio do potrzeb (226)
• Wytyczna 77. Stosuj vector w miejsce tablic (229)
• Wytyczna 78. W wymianie danych z interfejsami spoza C++ stosuj vector (i string::c_str) (231)
• Wytyczna 79. W kontenerach najlepiej przechowywać albo wartości, albo inteligentne wskaźniki do nich (233)
• Wytyczna 80. Sekwencję najlepiej rozwijać metodą push_back (235)
• Wytyczna 81. Od operacji na pojedynczych elementach lepsze są operacje na sekwencjach (237)
• Wytyczna 82. Do faktycznego przycinania kontenerów i faktycznego usuwania elementów najlepiej stosować sprawdzone idiomy (239)

• Wytyczna 83. Korzystaj z udogodnień kontrolnych implementacji STL (242)
• Wytyczna 84. Algorytmy są lepsze od pętli (245)
• Wytyczna 85. Wybieraj z STL właściwe algorytmy wyszukiwania (249)
• Wytyczna 86. Wybieraj z STL odpowiednie algorytmy sortowania (251)
• Wytyczna 87. Predykaty powinny być funkcjami czystymi (254)
• Wytyczna 88. W wywołaniach algorytmów miejsce funkcji powinny zajmować obiekty funkcyjne (256)
• Wytyczna 89. Zadbaj o poprawność obiektów funkcyjnych (258)

• Wytyczna 90. Zamiast przełączania pomiędzy typami stosuj polimorfizm (262)
• Wytyczna 91. Polegaj na typach, nie na reprezentacjach (265)
• Wytyczna 92. Unikaj rzutowania reinterpret_cast (267)
• Wytyczna 93. Unikaj rzutowania static_cast na wskaźnikach (269)
• Wytyczna 94. Zachowuj const przy rzutowaniu (271)
• Wytyczna 95. Nie korzystaj z rzutowania znanego z C (273)
• Wytyczna 96. Nie wolno brutalnie kopiować obiektów typów innych niż proste POD (276)
• Wytyczna 97. Unie nie służą do reinterpretacji reprezentacji (278)
• Wytyczna 98. Nie stosuj zmiennych list argumentów (trzykropków) (280)
• Wytyczna 99. Nie korzystaj z niepoprawnych obiektów i niebezpiecznych funkcji (282)
• Wytyczna 100. Nie wykorzystuj tablic polimorficznie (284)