Oracle, cz. 3

Wygląda na to, że w ciągu niespełna 6 miesięcy zostałem zakwalifikowany do rangi speca od oracla. Nie wiem czy cieszyć się że jestem taki cudowny (i skromny), czy też płakać że poziom innych ludzi jest taki niski.
Na dzisiaj kilka praktycznych porad dotyczących nazewnictwa zmiennych w PL/SQL (best practices for PL/SQL).

W PL/SQL często tworzymy kod, który jest zawiły. I tworzymy go jeszcze bardziej zawiłym. Dzieje się tak dlatego, że jest to język najwyraźniej stworzony przez nie-programistów (chociaż programiści też mieli w przy spory udział). Spotkałem się z kilkoma konwencjami, ale mi najbardziej przypadły do gustu następujące:

l_* : zmienne lokalne
g_* : zmienne zdefiniowane na poziomie paczki (głównym poziomie kodu)
c_* : stałe
*_curh : uchwyty do kursorów (gdy używam DBMS_SQL)
*_cur : kursory
*_i : iteratory (przy niejawnym ich tworzeniu, tj. FOR zmienna_i IN 1..10 LOOP NULL; END LOOP;)
*_ri : iteratory wierszowe - jak wyżej ale dla listy typu "select", gdzie obiekt jest typu %ROWTYPE
*_str : jeśli mam zmienne typu VARCHAR2 i chcę dodatkowo oznaczyć, że są to stringi

Słowa kluczowe piszę zawsze kapitalikami (tj. wielkimi literami).
Nazwy zmiennych staram się pisać małymi literami.
Nazwy kolumn, table, itp. staram się zaczynać wielką literą i używać tzw. "Camel Notation".
Przez pewien czas starałem się używać wielkich liter do oznaczenia wszystkiego, co jest dla mojego kodu "zewnętrzne". Ta zasada sprawdza się do momentu, gdy coś "zewnętrznego" staje się naszą implementacją, lub coś naszego wyrzucamy na zewnątrz.

Procedury, wyjątki, funkcje - nie mają żadnych przedrostków ani przyrostków. Ich nazwa ma tłumaczyć co robią.

Komentarze: Pisz jak chcesz ale zawsze komentuj dlaczego, nigdy "jak".