Rozdział 3. EKG2 developer handbook

Spis treści

EKG2 developing
Tips for coders
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

EKG2 developing

Tips for coders

  • If you are fixing/adding something, keep style from rest of the code. Make indentations by tab characters, not space. Make spaces after commas or semicolons. If you have other style, but your patches will be good and/or necessary don't be suprise if Your code will be changed.

  • Add yourself to copyrights at the beginning of the file. If you don't do it I found that you relinquish your code. Of course sended code must be on the same licence as the rest of the code. If not don't waste your time and don't send it to us.

  • Keep conventions. If all structure's variables have names like foobar_count, don't add foocount, or nfoo.

  • Don't change api without reason. Even if you want to do it, consult with other developers.

  • If you are making some bigger part of the code/module/file designed to some function, try to call functions and vars in way that can be understandable by other developers. Example: function connected with list are beginning with list_*, userlist functions userlist_*, configuration is something like config_*.

  • For memory allocation use xmalloc(), xcalloc(), xrealloc() and xstrdup(). You don't have to check returned value. If there will be no memory, these functions will handle soft program close. Look after freeing buffors, if they are not needed anymore.

    Instead of strncpy() and strncat() use strlcpy() and strlcat(), which takes as a parametr full buffer size. You don't have to worry about how much memory is left, if zero character will go, etc. Both functions always return number of characters, which were saved to the buffer.

  • If you don't know anything about memory allocation and string support in C, better find something else to do. Even if code is correct, but it is disordered it will be refused.

  • 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

Everyone can send patches, if they are respecting conventions. It is about saving our project from disorder after one month. Of course every change will be checked and if there is something wrong author will be rebuked.

API

API documentation is avaiable on project homepage: http://www.ekg2.org/en/doxygen/