Dlaczego w C++ jest lepiej?

Skusiłem się do napisania tej notatki w wyniku pogłębiającej się frustracji i zażenowania jakie mnie ogarnia, gdy po raz kolejny przeglądam jakiś dowolny kod źródłowy napisany, według jego autora, w C++. Niestety dosyć często zdarza się, że w rzeczywistości w ogóle to niewiele ma wspólnego z tym językiem. Zastosowane techniki i styl mówią coś zupełnie innego. Jedyne co może łączyć z językiem C++ to użycie rozszerzenia .cpp dla plików źródłowych, zamiast .c.

Niniejszy blog jest chyba najwłaściwszym miejscem do wyładowania mojej “agresji” i niezadowolenia oraz przedstawienia tych fragmentów kodu źródłowego, które doprowadziły mnie do takiego stanu. Zaprezentowanie takiego wycinka kodu z komentarzem i wyjaśnieniem co i dlaczego mi się nie podoba, co według mnie jest paskudne i nieodpowiednie, może być całkiem ciekawym doświadczeniem i zachętą do dyskusji nad jakością kodu. Takie wpisy mogą nieco poprawić merytoryczną zawartość bloga, bo to prawda, że dosyć rzadko coś ciekawego tutaj się ostatnio pojawia. Ale jak sam napisałem w notce o zmianach na devblogu, nigdy nie chciałem traktować tego miejsca tak typowo dokumentalno-manualowego, a bardziej jako miejsce prezentacji swoich uwag, spostrzeżeń i przemyśleń.

Najważniejszą częścią takich notatek byłyby uwagi w stylu “co i jak” według mnie należy zmienić w kodzie, dlaczego lepiej “zrobić to tak, a nie inaczej”. Wykorzystując czasem bardzo proste mechanizmy języka C++ można poprawić nie tylko działanie, czy czytelność samego kodu, ale także uniknąć wielu błędów na jakie mógłby natknąć się programista używający tych “dziwnych” i nieodpowiednich konstrukcji (w dużej mierze rodem z C). Przedstawienie moich własnych (i zapewne wielu innych programistów) dobrych praktyk, technik i stylu programowania w języku C++ mogłyby pomóc komuś dostrzec i zrozumieć podstawowe aspekty programowania w tym wspaniałym języku.

Idealnie pasuje w tym miejscu przytoczenie kilku słów A. Koeniga ze wstępu z jednej z jego książek¹, które bardzo dobrze opisują przyświecającą mi ideę i odzwierciedlają moje motywy działania:

Moim zamiarem nie jest nauczanie języka C++, a pokazanie, w jaki sposób myśleć podczas programowania w C++, jak podchodzić do problemów programistycznych i jak rozwiązywać je za pomocą kodu C++. Wiedzę można zdobywać systematycznie, z mądrością jest inaczej.

Nie jestem żadnym autorytetem, ani jakimś guru. Nie chcę również być uważany za jakiegoś ewangelistę C++, czy nowoczesnego programowania w tym języku (modern C++). Po prostu jestem programistą C++. Chyba nienajgorszym, a na pewno nie najlepszym, ale posiadającym już jakieś tam doświadczenie, a przecież z nim idzie ta cała reszta.

Na przestrzeni pewnego okresu zajmowania się daną tematyką dochodzimy do takiego momentu, że posiadamy wypracowany swój własny styl i technikę używaną na co dzień w pracy. Do wielu z nich dochodziliśmy długą i ciężką drogą, czasami nawet na własnych błędach. Za każdym razem korygując i usprawniając swoją pracę ciągle dążąc do perfekcji.

Jakiś wkład w to ma również code-review i to nie tylko własnego kodu, jaki stworzyliśmy, ale przede wszystkim tego zewnętrznego. Jesteśmy programistami, dziennie przeglądamy setki linijek kodu, a tym samym poznajemy punkty widzenia, style i techniki wykorzystane przez innych. Nierzadko w ten sposób możemy nauczyć się czegoś nowego, poznać inne, czasem o wiele lepsze rozwiązania, na które nigdy byśmy nie wpadli, a tym samym wykorzystali w swoich produkcjach.

Przeglądanie cudzego kodu pozwala w jakimś stopniu wyrobić i ukształtować nawyki i dobre zwyczaje w programowaniu, szczególnie patrząc na kolejny paskudny kod, napisany przez genialnego programistę, który chyba pomylił zawody. W takich sytuacjach analizując kod, często układa nam się wizja jakby on wyglądał, gdyby autor zastosował choć kilka prostych zmian i możliwości oferowanych przez język. Tych nawyków i tricków nam już znanych i używanych bezwarunkowo, bo stały się one jakby niepisanym standardem pozwalającym tworzyć nie tylko lepszy i czytelniejszy kod, ale unikać też wielu potencjalnych sytuacji do pomyłek i błędów.

Każdemu może się zdarzyć, że coś nie wychodzi dobrze. Znam wielu dobrych specjalistów w różnych obszarach IT i szeroko pojętego software developmentu i security, którym pisanie w “prawdziwym” C++ niezbyt dobrze wychodzi. Programy działają, zawierają kilka błędów (przecież idealne oprogramowanie nie istnieje!), ale zastosowany styl i technika często woła o pomstę do nieba. Niektóre błędy wynikają z braku znajomości możliwości języka C++. A wszystko pisane w stylu C. W końcu większość z nich to “niskopoziomowcy”, na co dzień grzebiący w binariach, asemblerze, a do C++ przechodzą głównie z C wraz z całym jego bagażem i starymi nawykami, które w C++ stają się udręką.

Najbardziej co mnie przeraża i boli to właśnie pisanie w C++ w stylu C. Nie mam nic do programistów C, którzy używają C++ jako lepsze C. Wielu programistów języka C tak zaczyna swoją przygodę w świecie C++, ale niestety nie wielu z nich przechodzi na następny poziom. A co gorsza, w dużej mierze nie zdają sobie sprawy, że w C++ mogą dużo łatwiej osiągnąć większą wygodę tworzenia i pielęgnowania kodu. To wszystko przy użyciu nawet elementarnych możliwości i funkcji jakie oferuje język C++. No, ale żeby do tego dojść trzeba poznać język i jego możliwości.

Nie będę tutaj teraz rozpisywał się na temat tego dlaczego w wielu sytuacjach w C++ byłoby lepiej niż w C, bo dosyć ciekawe uwagi i wnioski można znaleźć w kilku początkowych rozdziałach książki Andrewa Koeniga i Barbary Moo o tytule “Język C++. Koncepcje i techniki programowania”¹. Tytuł tej notatki nawiązuje i abstrahuje w pewnym sensie do podtytułów kilku początkowych rozdziałów i podrozdziałów tejże książki - “Dlaczego… C++…”.

Skoro już jesteśmy przy temacie książek, to zdaję sobie sprawę, że zapewne część tematów i aspektów jakie poruszę będzie można znaleźć w wielu książkach i publikacjach, jak chociażby autorstwa Meyersa ze słowem “effective” w tytułach lub innych traktujących o stylach i technikach programowania. Będzie to jedynie świadczyć o tym, że nie tylko ja myślę podobnie, a inni, lepsi i guru się ze mną zgadzają, co będzie na pewno miłym aspektem ;)

Nawiązując jeszcze do tematyki języków C i C++ to ciekawe informacje, które może pomogą zmienić nastawienie co bardziej zatwardziałych zwolenników tego pierwszego oraz obalić kilka mitów jakie wyrosły wokół tego drugiego, szczególnie w społeczności programistów języka C jest rozdział C mówimy nie! (małe advocacy) oraz Wiadomości wstępne w publikacji Sektora pt. “C++ bez cholesterolu”.

Dla tych, którzy chcieliby poznać dlaczego, niektóre elementy języka “wyglądają tak a nie inaczej”, zrozumieć założenia jakie przyświecały podczas projektowania języka, konkretne cele i zasady mające wpływ na jego kształt, polecam lekturę książki “Projektowanie i rozwój języka C++” samego twórcy języka C++ pana Bjarne Stroustrupa. Pozycja ta wraz z jego pierwszą książką o C++ - “Język C++” tworzą taką biblię dla programisty C++ ;)

Odnośnie zapowiedzianych notatek, to myślę, że będą one się pojawiać nieregularnie w różnych odstępach czasu. Ich poziom będzie zróżnicowany i w przypadkowej kolejności, zależnie od natchnienia - czyli jutro może być coś prostego i łatwego, o czym wszyscy wiedzą i (prawie) wszyscy stosują, a pojutrze coś cięższego, po czym znów powalę bardzo niskim poziomem przyziemnych spraw. Notatki będą prócz standardowych etykiet (C++, programowanie) tagowane również jakimś specjalnym do tego celu tagiem, aby łatwo można było wyodrębnić wszystkie wpisy.

To teraz należy cierpliwie czekać na sytuację, w której trafię na “genialne” rozwiązanie, dziwny styl lub technikę w przeglądanym kodzie, na coś co przysporzy mnie o ból głowy i zirytuje… Wierzę, że wtedy znajdę czas, aby potencjalną frustrację wylądować na blogu w postaci wartościowego wpisu przedstawiając jak to w mojej ocenie należy zrobić lepiej. Oczywiście czasem też mając trochę wolnego czasu mogą pojawić się notatki nie bazujące na żadnym kodzie, a przedstawiające jedną z dobrych praktyk czy reguł pragmatycznego programisty C++ ;)

Mały disclaimer:
Mam nadzieję, że nikt się nie obrazi jeśli natrafi w którejś notatce na swój kod lub zostanie podany jako autor danego fragmentu. Nie chcę nikogo obrażać ani bezpodstawnie krytykować (prócz konstruktywnej krytyki), a tym bardziej wytykać palcami błędów (to chyba będzie się zdarzało), czy, o zgrozo, podważać czyjeś kompetencje. To nie jest moim celem i zamierzeniem, po prostu wykonuję swoją pracę, robię to co muszę zrobić ;)