Rozdział 3. Podręcznik developera ekg2

Spis treści

Rozwijanie kodu ekg2
Wskazówki dla programistów
API
Formaty plików
Format listy kontaktów ekg2
Format konfiguracji ekg2
Format emotikon
Format kolejki wiadomości
Format pliku konfiguracji sesji ekg2
Debugowanie
Tworzenie tematów graficznych
Stworzenie nowego tematu
Formatki
Dopełnianie do szerokości
Końcówki zależne od płci
Znaki zachęty
Użytkownicy spoza listy kontaktów
Prompty readline
Marginesy
Tworzenie pluginów
Struktura plugin_t
Obsługa zdarzeń
Wywoływanie poleceń ekg2
Wyświetlanie danych

Rozwijanie kodu ekg2

Wskazówki dla programistów

  • Gdy coś poprawiasz/dodajesz, zachowuj styl reszty kodu. Wcięcia rób znakami tabulacji, a nie spacjami. Stawiaj spacje po przecinkach i średnikach. Jeśli masz inny styl, a podesłane poprawki będą dobre i/lub potrzebne, nie zdziw się, jeśli Twój kod zostanie przeregadowany.

  • Dopisuj się do copyrightów na początku pliku. Inaczej zakładam, że zrzekasz się praw do podesłanych kawałków kodu. Oczywiście podsyłany kod musi być na takiej samej licencji, co reszta. W innym wypadku nie trać czasu i go nie przysyłaj.

  • Zachowuj przyjętą konwencję. Jeśli wszystkie zmienne danej struktury mają nazwy typu foobar_count, nie dodawaj foocount, czy nfoo.

  • Nie zmieniaj api bez powodu. Nawet jeśli chcesz to zrobić, skonsultuj z resztą developerów.

  • Tworząc większy kawałek/moduł/plik przeznaczony do jakiejś konkretnej funkcji, staraj się nazywać funkcje i zmienne tak, by było wiadomo, do czego służą. Przykład: funkcje dotyczące list zaczynają się list_*, funkcje dotyczące userlisty to userlist_*, konfiguracja to config_*.

  • Do alokacji pamięci używaj funkcji xmalloc(), xcalloc(), xrealloc() i xstrdup(). Nie musisz sprawdzać zwracanej wartości. Jeśli zabraknie pamięci, funkcje te same zajmą się grzecznym zamknięciem programu. Dbaj o zwalnianie buforów, gdy nie są one już potrzebne.

    Zamiast strncpy() oraz strncat() używaj strlcpy() i strlcat(), które przyjmują jako parametr całkowity rozmiar bufora. Nie trzeba się martwić o to, ile w buforze pozostało jeszcze miejsca, czy znak zerowy się zmieści, etc. Obie funkcje zawsze zwracają ilość znaków, jaka została(by) zapisana do bufora.

  • Jeśli nie masz pojęcia o alokacji pamięci i obsłudze stringów w C, najlepiej daj sobie spokój. Nawet jeśli kod działa, ale nie trzyma się kupy, zostanie odrzucony.

  • Podsyłając patche, twórz je poleceniem diff -u. diff bez parametrów generuje patche, które nie zawierają żadnego kontekstu i ciężko je dołączyć do źródła, gdy zmieniła się wcześniej chociaż jedna linijka. Patche najlepiej generować względem najświeższej wersji, ale nie jest to wymagane, jeśli w międzyczasie nie było poważnych zmian w kodzie.

  • Jeśli poprawka jest niewielka (jedna, dwie linijki), nie trać swojego, ani mojego czasu, tylko po prostu wklej oryginał i poprawioną wersję do treści listu.

  • Poniższe linijki dopisane do ~/.vimrc ułatwiają wychwytywanie znaków niedrukowalnych pozostawionych na końcach linii poprzez zmianę ich koloru:

    
        highlight WhitespaceEOL ctermbg=red guibg=red
        match WhitespaceEOL /\s\+$/
    
                   
  • Wszelkie komentarze powinny być w języku angielskim.

  • Wszystkie formatki i wszystko co zostaje wyświetlane na ekranie ma być w języku angielskim.

  • Po zmianie jakiejkolwiek formatki należy w katalogu po/ wywołać make update-po i ewentualnie poprawić pliki *.po

Każdy może podsyłac patche, byle były zachowane pewne zasady i nie było po miesiącu bałaganu w kodzie. Oczywiście wszystkie zmiany będą przeglądane i w razie czego autor dostanie po łapach.

API

Dokumentacja API dostępna jest na stronie domowej projektu: http://www.ekg2.org/doxygen/