Konwencja programowania

W programowaniu obiektowym wydzielenie poszczególnych obiektów biznesowych do osobnych klas nie tylko porządkuje strukturę programu, ale ułatwia również modyfikowanie w późniejszym czasie. Jednak samo rozbicie na osobne obiekty niewiele da, jeśli programista nie będzie w stanie zorientować się w kodzie poszczególnych metod. Dlatego tak ważne jest stosowanie jednolitej, z góry ustalonej i spójnej dla całego projektu konwencji programowania.

Pod „konwencją programowania” rozumiemy konwencję nazewniczą dla zmiennych, klas i metod, ale również sposób komentowania, opisywania kodu, czy np. taki „drobiazg”, jak jednolity sposób tworzenia wcięć w kodzie.

Mimo że wszystkie te elementy na pierwszy rzut oka wydają się mało istotne, w praktyce okazują się dużym ułatwieniem w procesie tworzenia oprogramowania i późniejszej jego modyfikacji. Postaramy się przedstawić kilka najważniejszych.

Struktura programu

W początkowym etapie tworzenia nowego oprogramowania pierwszą rzeczą, na jaką mamy wpływ, jest jego struktura. Stosując metodykę programowania obiektowego, powinniśmy starać się przenosić jak najwięcej kodu do odpowiednich metod odpowiednich klas.

Niestety, część kodu musi pozostać bezpośrednio w programie (chociażby poszczególne zdarzenia) i w tym momencie system pozwala nam wybrać, czy rozdzielić kod na osobne pliki (tzw. Include), czy tworzyć wszystko w jednym.

Zasady kodowania

Dobrą praktyką, szczególnie w projektach, w których przewidywanych jest dużo prac programistycznych, jest utworzenie jednego zbiorczego dokumentu zawierającego wszystkie zasady kodowania.W takim dokumencie powinny zostać zgromadzone zasady dotyczące:

  • struktury programów
  • przyjętego schematu nazewnictwa dla wszystkich elementów programów
  • tworzenia i nazywania elementów słownikowych SAP (m.in. sposób buforowania tabel, zasady tworzenia indeksów itp.)
  • komentowania programów (komentarze w kodzie, schemat nagłówka każdego pliku zawierający podstawowy opis pliku itp.)
  • inne pożądane przy prowadzeniu prac programistycznych

Powinniśmy starać się rozdzielać program na osobne pliki, zachowując oczywiście z góry ustalony porządek. Na przykład w jednym pliku możemy przechowywać metody PBO (Process Before Output)  poszczególnych ekranów programu, w drugim metody PAI (Process After Input), a w jeszcze innym deklaracje wszystkich zmiennych wykorzystywanych w programie.

Jeśli wiemy, że każdy z ekranów będzie zawierał dużo zdarzeń, możemy pójść dalej i podzielić metody na pliki według ekranów, do których są przypisane. Dzięki podziałowi programu na kilka Include’ów, porządkujemy jego strukturę, ułatwiając sobie i innym programistom znalezienie interesującego nas kawałka kodu.

Pretty Printer

Kolejny element to Pretty Printer –  funkcjonalność udostępniona przez środowisko programistyczne, dzięki której jednym kliknięciem możemy sformatować cały kod w aktualnie otwartym pliku. Niestety, pomimo praktycznie zerowego nakładu pracy (wystarczy wcisnąć jeden przycisk menu lub kombinację SHIFT + F1) wiele osób nie korzysta z tej funkcji.

Trudno oceniać, czy jest to błąd czy nie; pewne jest jednak, że dzięki Pretty Printer kod programu zostaje sformatowany do wcześniej ustalonego wzorca. Oczywistym plusem tego jest znaczne zwiększenie przejrzystości kodu.

Dodatkowo osoba znająca kod programu, wiedząca, jak powinno wyglądać źródło po sformatowaniu, jest w stanie wyłapać wcześniej niezauważone błędy – ponieważ Pretty Printer przestaje formatować kod po napotkaniu błędu w składni programu.

Ważne jest jednak, aby wszyscy programiści biorący udział w projekcie mieli jeden ustalony styl formatowania kodu. Dzięki temu unikniemy sytuacji, gdy jeden z programistów, używając Pretty Printer, całkowicie zmieni formatowanie, utrudniając tym samym odczytanie programu pozostałym osobom.

Jedna konwencja

Chociaż każdy programista wie, że należy komentować kod programu, style i sposoby komentowania są skrajnie różne. Zaczynając od osób, które komentują prawie każdą linijkę kodu, kończąc na osobach, które w jednym zwięzłym zdaniu opisują wyłącznie przeznaczenie metody. Każdy sposób ma zalety i wady, najważniejsze jednak jest, aby styl komentowania programów w całym projekcie był jednolity.

Dzięki przyjęciu wspólnej konwencji każdy programista będzie od razu wiedział, gdzie może szukać potrzebnej mu informacji. Bez względu jednak na przyjętą konwencję komentowania istotne jest, by była ona ustalona na początku projektu.

Komentarze – naprawdę warto

Komentowanie poszczególnych metod może być istotną pomocą w trakcie tworzenia programu. O ile na początkowym etapie prac każdy wie, do czego służą poszczególne metody i jakie parametry powinny zostać przekazane, o tyle w późniejszym okresie gdy projekt się rozrośnie, tego typu informacje łatwo zapomnieć.

Dlatego warto komentować metody. Podstawowe minimum to jedno, dwa zdania mówiące o tym, co dana metoda robi, do czego służy. Warto jednak poświęcić chwilę i opisać znaczenie poszczególnych parametrów. Dzięki temu, gdy za jakiś czas będziemy chcieli skorzystać z tej metody, będziemy dokładnie wiedzieli, do czego ona służy i co należy przekazać w poszczególnych parametrach.

Kolejną ważną rzeczą jest komentowanie samego kodu, „ciała” poszczególnych metod. Nie zalecamy komentowania każdej linijki. Tak duża liczba komentarzy skutecznie utrudnia późniejsze czytanie kodu. Jednocześnie duża część kodu programu jest po prostu jednoznaczna i nie wymaga dopowiedzeń (np. podstawowe operacje przypisań, proste operacje arytmetyczne itp.).

Inspektor kodu

W projekcie, w którym stosowana jest jednolita, określona na początku konwencja nazewnicza, dobrym pomysłem jest, by pod koniec fazy implementacji zastosować narzędzie dostarczane przez SAP: Inspektor Kodu (Code Inspector) – transakcja SCI.

Dzięki Inspektorowi Kodu mamy możliwość przeprowadzenia swoistego audytu wykonanych prac programistycznych. Na podstawie zasad przyjętych w projekcie definiujemy określone reguły, które mają być zweryfikowane i sprawdzone przez Inspektora Kodu. Możemy zaprogramować kontrole na różnych poziomach poprzez przyporządkowanie określanym rozbieżnościom pomiędzy programem a przyjętymi zasadami odpowiednich priorytetów.

Zaleca się, aby audyt kodu przeprowadzany był przez osobę niebiorącą bezpośredniego udziału w pracach programistycznych. Dzięki świeżemu spojrzeniu na stworzone oprogramowanie będzie ona w stanie wychwycić więcej błędów niż programista biorący czynny udział w projekcie. Często zdarza się, że nowy programista, analizując tok myślenia twórcy programu, zauważa nową możliwość przebiegu procesu, której nie zauważył autor.

Jeśli jednak część naszej metody zawiera w sobie bardziej skomplikowaną logikę, warto opisać jej przebieg, ewentualne rozgałęzienia i skutki poszczególnych rozgałęzień (szczególnie skomplikowane konstrukcje zawierające instrukcje IF… ELSE… ENDIF, LOOP… ENDLOOP, CASE… WHEN… ENDCASE itp.).

Dzięki temu ułatwimy zrozumienie naszego toku myślenia osobie, która będzie zmuszona prześledzić działanie programu, ewentualnie wprowadzić modyfikacje do naszej metody. Powinniśmy zwrócić też uwagę, by nasze komentarze były zwięzłe i rzeczowe, bez zbędnego wdawania się w szczegóły nieważne dla opisywanego fragmentu kodu.

Jeśli już zdarzy się, że będziemy musieli coś zmienić lub poprawić we wcześniej napisanej metodzie, dobrą praktyką jest opisanie poszczególnych zmian. Powinniśmy zaznaczyć, kto i kiedy dokonał zmiany oraz jaki był powód i cel dokonanej modyfikacji.

Ułatwi to odtworzenie logiki, jaka kierowała programistą podczas tworzenia oryginalnej metody i późniejszych modyfikacji. A to z kolei w późniejszym czasie ułatwi nam dokonanie kolejnych modyfikacji – jeśli takie będą konieczne.

Określenie jednolitych zasad kodowania na początku projektu to zadanie pracochłonne i wymagające czasu, jednak przestrzeganie i egzekwowanie tych zasad może bardzo ułatwić zarządzanie kodem, jego zmianami oraz istotnie zwiększyć jakość stworzonego rozwiązania programistycznego.