Spis treści
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.
Dokumentacja API dostępna jest na stronie domowej projektu: http://www.ekg2.org/doxygen/