Utrzymanie i konserwacja
Unikaj pisania całego wyrażenia IF end w pojedynczej linii.
Łatwość śledzenia
Zmienne globalne z prefixem GLO, bez ":" na końcu !
Spójność
Zmienne lokalne bez prefiksu LOC
Spójność
Kod oprócz etykiet powinien rozpoczynać sie w 3 linii. Wcięcia dla wyrażeń kończonych komendą END, 2 spacje. (Accept, Loop, If, Case, Execute)
Spójność
Używaj END !Wyrażenie zamiast kropki na końcu. np.:
Accept
Loop While Something = True
Case ActionCode
OF AddRecord
Do AddRoutine
OF ChangeRecord
Do ChangeRoutine
Else
Do DefaultRoutine
End !Case ActionCode
If Expression = True
And SomethingElse > LowValue
Another Expression
End!If Expression = True ...
End !Loop While Something = True
End !Accept
Łatwość czytania i analizowania
Wyrażenia logiczne powyżej 5 poziomów zagnieżdżeń powinny być w osobnych routinach.
Łatwość czytania i analizowania
Zalecana maksymalna wielkośc routine to 40 linii
Łatwość czytania i analizowania
Wszystkie wyrażenia powinne być w trybie twierdzącym. Nie używać NOT
Łatwość czytania i analizowania
Uzywaj <> jako “różne od”.
Spójność
Nie używaj średników, nie umieszczaj kilku instrukcji w jednej linii.
Łatwość czytania i analizowania
Unikaj pisania linii kodu powyżej 80 kolumny. Użyj aby kontynuować pisanie kodu w następnych liniach. Jeśli kontynuujesz wyrażenie w komendzie IF przesuń następna linię o 1 spację.
Łatwość czytania i analizowania
Umieść co najmniej po jednej spacji przed i po znaku = . Użyj więcej znaków aby wyrównać znaki = w większych fragmentach instrukcji przypisania.
Łatwość czytania i analizowania
Używaj Like kiedy definiujesz zmienne ze sobą powiązane.
Utrzymanie
Często używaj pustych linii w celu odseparowania różnych fragmentów kodu .
Łatwość czytania i analizowania
Umieszczaj skomentowane linie (!-----) o długości 80 znaków na początku i końcu każdej podprocedury (routine), procedury, oraz w celu oddzielenia powiązanych fragmentów danych.
Łatwość czytania i analizowania
Kod powinien być czytelny i samodokumentujący. Komentarz powinien być umieszczony w tej samej linii dla każdego nietrywialnego wyrażenia. Każda procedura powinna być opisana z podaniem nazwy autora, daty utworzenia i modyfikacji. Informacja te powinna być uaktualniane przy każdej modyfikacji tej procedury.
Łatwość czytania i analizowania, utrzymanie
Należy używać kodu OOP, zgodnego ze standardem ABC Templates.
Utrzymanie
Umieszczaj jedną podprocedurę (routine) we wstawce (embed). Pierwsza linia powinna zawierać nazwe podprocedury i krótki jej opis. W dalszych liniach powinien być dokładny opis tego co podprocedura wykonuje.
Łatwość czytania i analizowania
Po operacjach I/O należy sprawdzać errorcode().
Unikanie błędów.
Nazewnictwo
Standard
Komentarz
Nazwy zmiennych powinny być oczywiste (należy unikać skrótów) skróty są akceptowalne przy nazwach dłuższych niż 20 znaków.
Self-documenting code.
Wszystkie pliki powinny mieć nazwy 16 bitowe (8+3 znaków). Wewnątrz programu nie używamy nazw długich, jednak program musi umożliwiać wprowadzanie i przechowywanie długich nazw plików.
Kompatybilność wstecz.
Nazewnictwo procedur
Browse
Brw
Form
Frm
Frame
Main
Process
Pro
Report
Rep
Source
Src
Splash
Spl
Viewer
Vie
Window
Win
Spójność
Nazwy procedur w menu (tzw. MenuText) jeśli aplikacja ma polski interfejs, jest polskojęzyczna to nie można stosować nazewnictwa nazw własnych oraz form rozkazujących zamiast imiesłowowych, np. "Wpisz AkcjeReklamowezZamówieńDoFaktur", powinno być "WpisanieAkcjiReklamowychZZamówienDoFaktur".
Standard
Komentarz
Nazwy zmiennych powinny być oczywiste (należy unikać skrótów) skróty są akceptowalne przy nazwach dłuższych niż 20 znaków.
Self-documenting code.
W modułach aplikacji kompilowanych jako *.dll wszystkie procedury są podłączone do lokalnego Menu (procedura typu Frame); nazwa procedury Menu pochodzi od nazwy aplikacji (modułu app, np. MenuDokumenty, MenuRaporty,MenuAdmin).
Brak komentarzy:
Prześlij komentarz