Wcześniej napisałem o pisaniu kodu na skróty, ale nie określiłem co jest na skróty a co nie jest … Warto to mieć gdzieś spisane i dostępne pod ręką , unika się wtedy analizowanie czy „skrót”, który chce zastosować to już skrót czy może optymalna metoda zakodowania tego co własnie robimy.
Z tych najbardziej popularnych to :
– nie należy używać instrukcji „goto” – co ciekawe prawie każdy język ja ma … ciekawe dlaczego ? Wytłumaczeń jest kilka, ale najbardziej istotne jest to że kod z takimi kwiatkami jest mało czytelny i trudno go użyć bez większych modyfikacji w innym miejscu programu.
– nie należy używać zmiennych globalnych. Dane można przekazywać jako parametry w funkcjach i procedurach
– zakres dostępności zmiennych powinien być jak najmniejszy. W przypadku pogańskich języków programowania zmienne można deklarować bezpośrednio przed użyciem, clarion (z małymi wyjątkami) zmusza do deklarowania zmiennych w sekcji przeznaczonej na deklaracje, ale zmienna używana w routine powinna być dostępna tylko w routine, jeśli w procedurze deklarujemy wewnętrzne procedury to ich zmienne powinny być tez dostępne tylko w podprocedurach. Dla kilku procedur wspólna zmienna możemy zdefiniować w module grupującym te procedury. Globalne kolejki mają tendencje do wysypywania aplikacji (jest pewien problem ze współdzieleniem takich kolejek w wielu wątkach)
– stosuj wcięcia w kodzie. Kod odpowiedzialny za różne funkcjonalności rozdzielaj pustymi wierszami. Zdecydowanie poprawia to czytelność.
– kod powinien sam się dokumentować! Jeśli procedury i funkcje ponazywasz tak, że nazwa mówi do czego służy to analiza takiego kodu będzie dużo prostsza. Przy właściwym podejściu do tematu dodatkowe komentarze będą prawie zbędne, oczywiście bez utraty czytelności i łatwości analizy intencji programisty.
– unikaj zagnieżdżeń kodu, LOOP z CASE/IF/LOOP w środku jest jeszcze ok, ale kolejny wewnętrzny LOOP powinien być już zakodowany jako osobna funkcja/procedura. Jeśli trzeba przekazać sporo parametrów do takiej procedury, może warto te zmienne zgrupować w jakimś obiekcie i przekazywać pojedynczy obiekt zamiast kilkunastu parametrów ?
– funkcje powinny być krótkie, kiedys istniała dobra praktyka nie przekraczania wielkości ekranu, czyli jeśli kod funkcji nie mieścił się na ekranie bez przewijania to kwalifikował się do podzielenia. Warto tez przypomniec sobie, jakie wówczas były ekrany: 24*80 znaków. Obecnie ekrany są większe i mieszczą więcej kodu, jednak stopień percepcji programujących raczej się nie poprawił.
– w przypadku klas i obiektów interfejs komunikacji z nimi powinien być jak najwęższy, czyli cechy czynimy prywatnymi, dajemy możliwość ich modyfikacji tylko przez gettery i settery, a jeszcze lepiej (jeśli obiekt po utworzeniu nie będzie modyfikowany) jedynie przez konstruktor. Hermetyzacja rządzi ;).
– od kilku lat zwalczam w sobie wypełniania embeds kodem dłuższym niż 2 linijowym. Użycie takiego kodu w innym miejscu jest uciążliwe i prowadzi do wielokrotnego powtarzania fragmentów kodu w wielu miejscach programu. Zły przykład daje sam clarion, który wkleja spore fragmenty kodu w każdej z procedur, ale robi to z szablonów i nie ma problemów z wielokrotnym używaniem tej samej funkcjonalności w wielu miejscach i zwykle nie jesteśmy zmuszani do analizowania kodu wygenerowanego. Nie należy się sugerować tym co robi clarion, tylko zwracać na wybitnie długaśne fragmenty kodu własnego autorstwa.
Ciąg dalszy nastąpi …
Kashiash's Blog 