Symbian C++ jest językiem bardzo restrykcyjnym. Twórcy starali się ustandaryzować wszystko, włączanie z odpowiednim nazewnictwem w kodzie. A wszystko to między innymi, aby uniknąć błędów (np. wycieków pamięci) które są najdotkliwszymi błędami dla urządzeń posiadających małą ilość pamięci. Musimy pamiętać, że projektujemy właśnie dla takich urządzeń, gdzie pamięć jest ograniczona, a wszelkie rebooty następują o wiele rzadziej niż w przypadku komputerów klasy PC.

W poprzedniej notce zaprezentowałem w jaki sposób oznaczane są typy danych, dla przypomnienia – nazwę typu poprzedza duża litera T (od Type), natomiast zmienne które odpowiadają

unsigned posiadają przed nazwą typu (ale po T) dużą literę U (od unsigned). Poniżej przedstawiam podstawową konwencje nazewnictwa (na dobry początek ;)), której bardzo dobrze się trzymać:

  • Nazwy klas (prefiksy):
    • T – typy
      • Klasy T nie posiadają destruktora, występują w sposób jak typy wbudowane.
    • C – klasy
      • Klasy C to klasy dziedziczące po CBase.
    • R – zasoby
      • Klasy R to wszystkie klasy pośrednie (proxy) pomiędzy obiektami znajdującymi się gdzieś indziej.
    • M – interfejsy (Mixin)
      • Klasy M są interfejsami składającymi się z funkcji wirtualnych.
  • Nazwy danych (prefiksy)
    • E – stałe typów wyliczeniowych
      • Stała typu wyliczeniowego, powinna być składową stałej o nazwie rozpoczynającej się od T
    • K – stałe
      • Stałe. Po prostu.
    • i – zmienne składowe
      • Każda nie-statyczna zmienna składowa (i od instance).
    • a – argumenty
      • Wszystkie zmienne deklarowane jako argumenty.
  • Nazwy funkcji (sufiksy)
    • L – funkcje, które mogą _leave_ować (_leave_owanie zostanie wyjaśnione później).
    • C – funkcje, które zostawiają coś na _Cleanup Stack_u (Cleanup Stack zostanie wyjaśniony później).
  • Nazwy makr
    • Pisane dużymi literami, podkreślenia zamiast spacji.
  • Symbole wbudowane
    • Pisane z podwójnym podkreśleniem jako prefiks oraz sufiks.

Ufff, trochę tego jest. W ten sposób są zapisane biblioteki, więc dobrze jest sobie to wszystko zapamiętać, w późniejszych etapach będzie to umożliwiało łatwe rozpoznanie co użyć do zabezpieczenia danej klasy lub metody, czego unikać przy wkładaniu na Cleanup Stack, etc.

Następne notki będą traktowały o mechanizmie obsługi błędów/wyjątków, co jest chyba najważniejszym tematem w świecie Symbiana.